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

[Mohamad Badra <[e-mail]>]

For info, I submitted during 2007 and 2008 two documents to enable
authentication using passwords.

http://tools.ietf.org/id/draft-badra-tls-password-ext-01.txt
ftp://ftp.kfki.hu/pub/documents/iana/drafts/draft-badra-tls-password-00.txt

Both of them are simple, and secure enough to enable password-based
authentication

Best regards,
Badra



On Tue, Dec 3, 2013 at 10:08 PM, Watson Ladd <[e-mail]> wrote:

> On Tue, Dec 3, 2013 at 9:41 AM, Dan Harkins <[e-mail]> wrote:
> >
> > On Tue, December 3, 2013 8:12 am, Watson Ladd wrote:
> >> On Tue, Dec 3, 2013 at 12:50 AM, Dan Harkins <[e-mail]>
> wrote:
> >>>
> >>> On Mon, December 2, 2013 8:40 am, Watson Ladd wrote:
> >>>> On Mon, Dec 2, 2013 at 6:28 AM, Rene Struik <[e-mail]>
> >>>> wrote:
> >>>>> Dear colleagues:
> >>>>>
> >>>>> I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work
> >>>>> that
> >>>>> went into this draft, I have to concur with some other commenters
> >>>>> (e.g.,
> >>>>> Doug Stebila, Bodo Moeller) that it is unclear what makes this
> >>>>> protocol
> >>>>> special compared to other contenders, both in terms of performance
> and
> >>>>> detailed cryptanalysis. One glaring omission is detailed security
> >>>>> evidence,
> >>>>> which is currently lacking (cross-referencing some other standards
> >>>>> that
> >>>>> have
> >>>>> specified the protocol does not by itself imply the protocol is
> >>>>> therefore
> >>>>> secure). I am kind of curious what technical advantages the
> >>>>> "Dragonfly"
> >>>>> protocol has over protocols that seem to have efficiency, detailed
> and
> >>>>> crypto community reviewed evidence, such as, e.g., AugPAKE (which is
> >>>>> another
> >>>>> TLS-aimed draft) and others. So, if the TLS WG has considered a
> >>>>> feature
> >>>>> comparison, that would be good to share.
> >>>>>
> >>>>> I would recommend to ask CFRG to carefully review the corresponding
> >>>>> irtf-dragonfly-02 document (to my knowledge, there has been no LC and
> >>>>> it
> >>>>> is
> >>>>> still a draft document there) and align the TLS document
> >>>>> draft-ietf-tls-pwd-02 document with whatever comes out of that effort
> >>>>> (currently, there are some security-relevant differences). This time
> >>>>> window
> >>>>> could also be used for firming up security rationale, thus aleviating
> >>>>> concerns on that front.
> >>>> I do not like the way this standard mixes algorithmic details with
> >>>> instantiation
> >>>> details. It makes it hard for me to understand what the protocol
> >>>> actually
> >>>> is.
> >>>> I also do not understand why H needs to be a random oracle as opposed
> >>>> to
> >>>> something we have in the standard model.
> >>>
> >>>   It is difficult to understand how to act on this comment. The
> >>> specification
> >>> is of a cipher suite added to an existing protocol and as such has to
> >>> "mix" the
> >>> details of the underlying key exchange with the structure and format of
> >>> the
> >>> protocol it is being added to. It is not a high-level description of
> the
> >>> algorithm,
> >>> it is a description of how to implement the key exchange as a TLS
> cipher
> >>> suit.
> >> What protocol is this standard implementing? Where is it documented?
> Where
> >> is
> >> the security proof?
> >
> >   Do you have a specific comment on the draft itself? "I don't like it"
> is an
> > unactionable editorial comment.
> Yes: the draft is unacceptable from a cryptographic perspective
> because has a protocol
> that has not faced formal analysis or review by the cryptographic
> community, is not clearly
> presented, and has no analysis worthy of the name.
> The action is to write the protocol, formally prove it correct, submit
> the paper to a conference
> wait a few years, and then say "well, this works". Or use a theorem
> verifier to shorten the time.
> Rene Struik, Robert Ransom, and I all have the same opinion on the
> merits of this protocol: questionable at best.
> I believe this should be sufficient to prevent this draft from
> becoming a standard.
> >
> >>>> I also do not like the language of "commitment" used. What is sent is
> >>>> not a Pedersen commitment or any other recognizable commitment.
> >>>> It is very malleable in ways that make me question the informal
> >>>> security
> >>>> analysis.
> >>>
> >>>   Of course it's a recognizable commitment because it allows the sender
> >>> to commit to a particular value (the password) without exposing it to
> >>> anyone else.
> >> The sender is committed to the password, but not to the value of the PE
> >> point.
> >
> >   There is a one-to-one mapping of password (plus username and salt)
> > and point. If one is committed to the password, he's committed to the
> > point.
> No, because the point might not be from a password. He might not be able
> to show
> a password going to the point that he claims he was committed to, but
> that doesn't necessarily
> matter. Without a proof we have no idea how much it matters. Reading
> the draft I don't think
> the password needs to be guessed or known, but the point itself, and
> the attacker isn't bound
> to a choice of point.
> >
> >> This is noted in the "security analysis" section, but absent a proof I
> >> can't tell you
> >> that it doesn't matter. The security analysis section reads like a
> >> bunch of attacks
> >> were tried and failed. All that shows is *you* couldn't break it, not
> >> that anyone else
> >> couldn't.
> >>>
> >>>>> Two final comments:
> >>>>> a) It is unclear why one should hard code in the draft that elliptic
> >>>>> curves
> >>>>> with co-factor h>1 would be ruled out. After all, this would make it
> >>>>> much
> >>>>> harder to extend the reach of the draft to prime curves with
> co-factor
> >>>>> larger than one and to binary curves.
> >>>> I think the authors wanted to specify secure curves and haddn't the
> >>>> slightest to do it right.
> >>>
> >>>   (Note: I always like to have my intelligence questioned with a
> >>> statement
> >>> that has multiple grammatical errors).
> >> It's not your intell
> >
> >   Again, thank you for that comment.
> >
> As I ment to say, but due to an editing failure did not, it is not
> your intelligence I am questioning
> but your ability to do cryptographic work. The present draft shows no
> evidence of it. Of course,
> it turns out that you weren't attempting to specify secure curves, but
> unpatented ones. But all
> that matter is one curve has one implementation not reached by
> patents, not that the standard can only be used with unpatented
> implementations
> >>>   As I mentioned to Rene, the reason for limiting the curves to those
> >>> over a prime field with a co-factor of 1 is to avoid the patent mine
> >>> field.
> >> What mine field? What is so patented about cofactor>1 over prime field?
> >> For binary curves I agree.
> >
> >   There are plenty of patents that deal with acceleration when the
> > cofactor is > 1 or deal with verification of received elements when
> > the cofactor is > 1. I just don't want to deal with it.
> And so you preemptively limit the ability of implementers to use Ed25519 if
> they feel confident that it is not patented, or they don't need the
> "acceleration"
> that you claim is patented. It might be worthwhile to say everyone support
> P256
> so we can interoperate, but why rule out particular instantiations a
> priori? I just don't
> get the rationale here.
> >
> >>                                         But why not use whatever curve
> > TLS specifies?
> >> Also, why not use the existing mechanisms to deal with implementation
> >> limits
> >> caused by patents?
> >
> >   What mechanisms _speciifcally_ is TLS-pwd doing that is causing you
> > to say this? It uses the existing mechanisms provided by the base TLS
> > protocol to convey the group to use. Again, I don't know how to address
> > a comment that says to change the protocol to do what it already does.
> >
> >>>> Weierstrauß form has big problems: Edwards is much better from an
> >>>> implementation security
> >>>> perspective. Cofactor isn't enough: you also need high embedding
> >>>> degree, big discriminant,
> >>>> or you could just use curves we agree are good instead of reinventing
> >>>> the
> >>>> wheel.
> >
> >   "[U]se curves we all agree are good instead of reinventing the wheel"?
> Now
> > I'm starting to think you didn't even read the draft.
> We do not need 3 different places in the TLS handshake containing EC
> curve parameters.
> When a TLS client implementing this protocol talks to a server, it
> will send this extension with
> EC parameters, as well as EC parameters for the extensions permitting
> EC ciphersuites to be used,
> as well as special TLS ciphers saying it can use EC. This is ridiculous.
> Any gains from specifying the curves are lost because of the strong
> restrictions on shape.
> It's entirely possible that this is the best possible result given the
> current state of TLS, and my
> objection to the mechanism is not strong: my strong objection is from
> the lack of serious cryptographic
> effort in this draft and that we have no idea how strong this protocol is.
> >
> >   Dan.
> >
> >>>> Higher order protocols should be group agnostic.This prevents a major
> >>>> problem when
> >>>> Joux comes up with something new.
> >>>
> >>>   It specifies a single group for interoperability purposes. It's
> >>> "crypto
> >>> agility" is inherited from TLS.
> >>>
> >>>   Dan.
> >>>
> >>>>> b) The probabilistic nature of the "hunting and pecking" procedure
> may
> >>>>> be a
> >>>>> recipe for triggering implementation attacks. Wouldn't one be much
> >>>>> better
> >>>>> off removing dependency on non-deterministic password-to-point
> >>>>> mappings
> >>>>> (e.g., AugPAKE, Icart map, German BSI-password protocol)?
> >>>> Well, one could use Elligator to solve this problem.
> >>>>>
> >>>>> Best regards, Rene
> >>>>>
> >>>>>
> >>>>> On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote:
> >>>>>>
> >>>>>> This is the beginning of the working group last call for
> >>>>>> draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
> >>>>>> TLS-PWD
> >>>>>> has been reviewed by the IRTF CFRG group with satisfactory results.
> >>>>>> The
> >>>>>> document needs particular attention paid to the integration of this
> >>>>>> mechanism into the TLS protocol.   Please send comments to the TLS
> >>>>>> list
> >>>>>> by
> >>>>>> December 2, 2013.
> >>>>>>
> >>>>>> - Joe
> >>>>>> (For the TLS chairs)
> >>>>>> _______________________________________________
> >>>>>> TLS mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/tls
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> email: [e-mail] | Skype: rstruik
> >>>>> cell: [phone] | US: [phone]
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> TLS mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/tls
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> "Those who would give up Essential Liberty to purchase a little
> >>>> Temporary Safety deserve neither  Liberty nor Safety."
> >>>> -- Benjamin Franklin
> >>>> _______________________________________________
> >>>> TLS mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/tls
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> "Those who would give up Essential Liberty to purchase a little
> >> Temporary Safety deserve neither  Liberty nor Safety."
> >> -- Benjamin Franklin
> >>
> >
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>