ISE write-up for: draft-harkins-tls-dragonfly-02
'This memo defines several new ciphersuites for the Transport Layer
Security (TLS) protocol to support certificate-less, secure
authentication using only a simple, low-entropy, password. The
exchange is called TLS-PWD. The ciphersuites are all based on an
authentication and key exchange protocol, named "dragonfly", that is
resistant to off-line dictionary attack.'
This draft has IANA Considerations, it requests codepoints in the
TLS Extensions Registry, which need IETF Review. IANA say that
can't happen until the Expert Reviewers pool for that Registry
is set up. However, I don't think this draft's 5742 review
needs to wait for that.
It was reviewed for me by Jim Schaad, Wattson Ladd and Joe Salowey.
The author has made changes that address the issues raised by reviewers.
- - - - -
Jim Schaad's review:
General - The number of places in this document that are making assumptions
about the curve to be used is depressing. Does this scheme only work with
specific curves or is it general purpose? Walk through the document and
remove everything that would be different if I used X25519 as the curve and
put in general language in its place.
General - You do not need to duplicate the dragonfly draft in this draft.
Make this draft specific to TLS and not a general dragonfly primer.
Section 1.2 para 2 - This paragraph is not flowing well for me. I can
understand the first sentence and I can understand the second sentence,
however I cannot get from the first to the second sentence. For me they
appear to be independent sentences.
Section 1.2 para 3 - I believe that the second sentence should say that the
enumeration is being done off-line
Section 4 para 3 - The concept of modifying messages is anathema to me.
Note that I do not consider the definition of new extensions or
modifications at extension points to be a modification of messages and this
should be called out for what it does.
Section 4.1 - para 2 - This paragraph should be replaced with a sentence
about generating a public/private key pair. Details of crypto algorithms
are only needed if they are not covered else where
Section 4.1 - para 3 - why are you using a non-normal curve for your must
Section 4.1 - para 3 - the last sentence would be shorter to say that they
choices of curves are independent.
Section 4.1 - para 4 - I doubt that the server is doing the conveying here
in general. It would be better to break this into two sections - what is
provisioned on the server and what is provisioned on the client and ignore
how the provisioning is done unless you are going to define a protocol for
that purpose. One could, for example, see that this might be done via DANE.
Section 4.1 - para 5 - this text appears to say that non-compact
representation is not permitted. Is there a good reason for this? If so it
should be documented given that many if not most systems currently still
avoid compact representation for patent reasons.
Section 4.1 - para 5 - why is AES-SIV used here? This is not a mode that is
going to present today on TLS implementations. I am not sure that there are
any reasons not to use AES-GCM rather than AES-SIV if one derives both the
nonce and key.
Section 4.1 - para 5 - What happens if there is ever a problem that develops
with SHA-2 or AES? You are fixing the algorithms which means that there is
no flexibility for the future.
Section 4.1.1 - para 1 - The details of creating an ephemeral key and doing
the math can be omitted as being known.
Section 4.1.1 - para 1 - why use salt-less HKDF here, why not use a constant
string in case somebody does something stupid like using the same key for
both protecting the user name and as the ephemeral for the TLS conversation.
Section 4.1.1 - How is the username formatted? Is this a UTF8 string or is
it a binary value?
Section 4.1.1 - I am not sure that you are promoting a good method of
dealing with padding user names. I think you should be more proactive in
giving padding advice. It will still be possible to do analysis based on
short vs long names if one were to say - ok do a 1 to 5 byte length padding
on the user name. What happens if I were to pad by 256 bytes. It would
make more sense to either have a fixed length pad set by configuration of
the server or to give a number of recommended lengths to pad to. For
examples 128 bytes or 256 bytes as these are longer than user names are
going to be and therefore kill all of the traffic analysis.
Section 4.3.1 -- Is there a reason you are using saslprep rather than the
user name profile of RFC 7613
Section 4.3.2 - Don't allow for random parameters, use the key agreement
enumeration list instead as this is a better set of values.
General - Given the current mode of people, is there any reason to support
anything other than EC at this time?
Too tired to continue at this point
- - - - -
Wattson Ladd's review:
I've got several concerns about this draft.
For starters, Section 1.2 doesn't seem to fit the flow of the
document, and the substance seems off. Two references for password
normalization are to obsoleted RFCs: it would be nice to know the
reasons why the replacements cannot be used instead. Sentences such as
"The ability of each side to produce a valid finished message
authenticates itself to the other side." are utterly without sense:
does the ability authenticate itself, or the side authenticate by
producing a valid finished message? The assumptions paragraph belongs
in security considerations. Section 9 is ridiculable in its pomposity
and legally incorrect. Modifications to the ServerKeyExchange are not
defined in this document. With such basic editorial problems, I think
substantial revision is warranted.
There are technical issues as well. Brainpool256r1 is not widely
supported in TLS implementations, yet this draft demands it. Why?
Especially for IoT devices, supporting multiple curves is a burden,
and Brainpool is comparatively power hungry. Furthermore, it seems as
though cofactor >1 is artificially excluded, instead of multiplying by
cofactors or normalizing input points. This ensures that newly
standardized curves in the CFRG cannot be used with this draft.
Implementations do not select passwords: users do, and do so badly,
and users reuse passwords. There is no means to communicate the
username protection key to the client. Lastly, there are substantial
differences between the provably correct version and the version in
Several critical parameters are left up to the user to select, such as
m. It is also not defined when a password guess has taken place, which
is a subtlety in the proofs of all password based key agreements, and
may break security.
All this I saw in less than an hour. Careful editing would take
substantially more time.
- - - - -
Joe Salowey's review:
Here is my review (sorry for the delay):
I believe this document to be ready with a few comments the author may wish
- Section 1.1
PAP-style may not be a familiar term to TLS implementers, perhaps use
"basic password exchange" instead
- Section 3.2
Should the two instances of "EEC" be replaced with "ECC"?
- Section 3.2.1
The document may want to define a mandatory implement curve. Its not
critical, but I think it would help with interop.
- Section 3.2.2
I think it would be good to define a set of recommended to implement or
mandatory to implement finite field groups for this protocol. The list can
be taken from the IANA TLS named groups registry. These might be listed in
the cipher suite section.
- Section 4.1.1
Since the use of SIV encryption is deterministic the document should
mention here or in the security considerations that it is important to for
the client to generate a fresh random secret c every time to avoid leaking
information about the username.
- Section 4.2.2
Are you concerned about side-channels in the FFC password element
computation? The pseudo code is fine, but the description before the
pseudo code says:
"If the result is greater than one (1), the candidate password element
becomes PE, and the hunting and pecking terminates successfully."
Whereas the ECC section adds in the bit about m <= K
- section 4.3.1
Why do you allow the server to abort the connection early if the name is
not found? Should you mention security implications of revealing the
username? I don't think you need to mandate against it, but I think you
should describe that the consequences of terminating the exchange if a
password is not found is that you reveal that a username does or does not
- section 18.104.22.168.1
Explicit definition of curves is being deprecated in 4492-bis, only named
curves are moving forward.
- section 22.214.171.124.2
This text leaves me uncertain as to whether you intend to support the named
groups in the TLS IANA registry for FFC.
- section 126.96.36.199
Explicit definition of groups is deprecated in 4492-bis.
- section 188.8.131.52
- - - - -