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

From: Rene Struik <[email-masked]>
Date: Mon, 02 Dec 2013 09:28:29 -0500

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.

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.
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)?

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Watson Ladd <[email-masked]>
Date: Mon, 2 Dec 2013 08:40:26 -0800

On Mon, Dec 2, 2013 at 6:28 AM, Rene Struik <[email-masked]> 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.
>
> 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
> (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.

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.
>
> 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.
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.

Higher order protocols should be group agnostic.This prevents a major
problem when
Joux comes up with something new.
> 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.
>> 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)

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Robert Ransom <[email-masked]>
Date: Mon, 2 Dec 2013 11:30:42 -0800

On 12/2/13, Watson Ladd <[email-masked]> wrote:
>> is
>> window

I don't see what advantage their ‘committment’ [sic] provides over
using standard Diffie-Hellman with a password-derived secret
basepoint.  All of the protocol's security against offline attacks and
impersonation appears to be provided by requiring that both parties'
group elements are in the prime-order subgroup.

> Well, one could use Elligator to solve this problem.

The Elligator paper (published in August) cites a PAKE paper from 2001
as a possible use for injective maps.  The J-PAKE paper (published in
2008) states that there were no good unpatented PAKE protocols
available at the time J-PAKE was published, and even the patented
protocols were not secure.  Is this protocol related to the 2001
protocol, is that protocol patented, and if so, does that patent cover
this protocol?

Robert Ransom

---

From: Robert Ransom <[email-masked]>
Date: Mon, 2 Dec 2013 11:43:38 -0800

> protocol, is that protocol patented, and if so, does that patent cover

The J-PAKE paper includes a description of ‘SPEKE’ (according to the
citations, published in 1996 and patented in U.S. patent 6,226,383).
It is essentially DH with a secret base over a modular-multiplication
group.  The J-PAKE paper also mentions a theoretical attack that could
allow an attacker to test multiple passwords in one protocol
execution, although that doesn't seem plausible.

I guess someone will have to read the patent to find out whether it
claims PWD as well.

Robert Ransom

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 3 Dec 2013 00:27:40 -0800 (PST)

Dear Rene,

> others. So, if the TLS WG has considered a feature comparison, that

  dragonfly is a balanced PAKE kind of exchange and it has certain
advantages over augmented PAKE schemes like TLS-SRP (which, unlike
the augPAKE draft, is a published RFC that has been implemented).
Namely, the domain parameter set is not fixed with the password and
can be negotiated to provide security commensurate with that offered
by the rest of the cipher suite. And yes, the drawback of a balanced
PAKE scheme is that if the server is compromised and the password
file exposed then an attacker can impersonate users (although, in my
opinion, that is something of a dubious benefit since the server is
already compromised and this will be the least of your problems).

  This has already been discussed in this thread by the way.

> aleviating concerns on that front.

  This suggestion has already been done.

> co-factor larger than one and to binary curves.

  You're right, it does prevent the use of binary curves and prime curves
with a co-factor greater than one. That's the whole point. The motivation
is to avoid walking through a patent mine field.

> mappings (e.g., AugPAKE, Icart map, German BSI-password protocol)?

  The "hunting and pecking" procedure is deterministic otherwise there
would be no guarantee that each side arrived at the same element
given the same input.

  regards,

  Dan.

>> 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)

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 3 Dec 2013 00:50:40 -0800 (PST)

On Mon, December 2, 2013 8:40 am, Watson Ladd wrote:
>> that

  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.

> It is very malleable in ways that make me question the informal security

  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.

>> curves

  (Note: I always like to have my intelligence questioned with a statement
that has multiple grammatical errors).

  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.

> Joux comes up with something new.

  It specifies a single group for interoperability purposes. It's "crypto
agility" is inherited from TLS.

  Dan.

>> be a
>>> TLS-PWD

---

From: CodesInChaos <[email-masked]>
Date: Tue, 3 Dec 2013 13:19:18 +0100

The protocol uses a fast hash to hash the password.
The challenge-response nature of the protocol means that the sever
cannot apply additional hashing.
This implies that the server needs to store a badly hashed password
which is easy to crack
when the database is compromised. While the information on the wire
doesn't enable an offline dictionary attack,
database leaks are common. So being strong against those attacks is important.

Why did you use a fast hash like HMAC-SHA-256 over a proper password
hash like PBKDF2-HMAC-SHA-256?

Why does the security considerations section not mention password
guessing attacks / offline dictionary attacks against a compromised
database?

---

From: Rene Struik <[email-masked]>
Date: Tue, 03 Dec 2013 09:15:49 -0500

Hi Dan:

I could not find that CFRG had a LC on this. In case I missed this, 
please kindly provide a pointer.

Triggered by the TLS WG LC, I decided the review the Dragonfly protocol 
document last Friday (since TLS WG LC suggested CFRG had "blessed" this) 
and sent my review to the CFRG email reflector. One can find this review 
here:http://permalink.gmane.org/gmane.ietf.irtf.cfrg/2127 
<http://permalink.gmane.org/gmane.ietf.irtf.cfrg/2127>.

I suggest you have a discussion on how to fix security comments raised 
on the CFRG dragonfly protocol on that list.

As far as I am concerned, my TLS WGLC comments still stand.

Best regards, Rene

---

From: Watson Ladd <[email-masked]>
Date: Tue, 3 Dec 2013 08:12:27 -0800

> it is a description of how to implement the key exchange as a TLS cipher
What protocol is this standard implementing? Where is it documented? Where is
the security proof?
> to commit to a particular value (the password) without exposing it to
The sender is committed to the password, but not to the value of the PE 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.
> that has multiple grammatical errors).
It's not your intell
> 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. But why not use whatever curve TLS specifies?
Also, why not use the existing mechanisms to deal with implementation limits
caused by patents?

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 3 Dec 2013 09:41:30 -0800 (PST)

On Tue, December 3, 2013 8:12 am, Watson Ladd wrote:
>>>> which is currently lacking (cross-referencing some other standards
>>>> that
>>>> have
>>> details. It makes it hard for me to understand what the protocol
>>> actually
>>> is.

  Do you have a specific comment on the draft itself? "I don't like it" is an
unactionable editorial comment.

> The sender is committed to the password, but not to the value of the PE

  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.

>> that has multiple grammatical errors).

  Again, thank you for that comment.

> 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.

>                                         But why not use whatever curve
TLS specifies?
> Also, why not use the existing mechanisms to deal with implementation

  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.

>>> 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.

  Dan.

>>>>> mechanism into the TLS protocol.   Please send comments to the TLS
>>>>> list
>>>>> by
>>>>> December 2, 2013.
>>>>>
>>>>> - Joe
>>>>> (For the TLS chairs)

---

From: Watson Ladd <[email-masked]>
Date: Tue, 3 Dec 2013 10:08:47 -0800

> 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.
> and point. If one is committed to the password, he's committed to the
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.
>   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
> 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.
> 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.

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 3 Dec 2013 22:25:13 +0400

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 <[email-masked]> wrote:

> >> What protocol is this standard implementing? Where is it documented?
> Where
> >> is
> >> the security proof?
> >

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 3 Dec 2013 11:21:01 -0800 (PST)

> On Tue, Dec 3, 2013 at 9:41 AM, Dan Harkins <[email-masked]> wrote:
[snip]
> I believe this should be sufficient to prevent this draft from

  That is not a comment on the draft but on the process.

  Nothing is stopping you from working on some protocol that you
find value in and working to achieve consensus on it being the right
way to go but work was done on this protocol and consensus was
reached in the WG to proceed with it. The exchange was reviewed
by the CFRG with, as Joe noted, satisfactory results.

  You think that is unacceptable? OK, point noted.

> the password needs to be guessed or known, but the point itself, and

  No, the attacker is free to choose any point he wants. But since there is
a one-to-one mapping of password (plus username plus salt) to point
any guess of the password that is incorrect will produce the wrong point.
That's the whole point (pun intended).

> evidence of it.

  Whether you're questioning my intelligence or my ability to do crypto
is another unactionable editorial comment. And frankly I don't really
care whether you are impressed with my abilities or not.

>                        Of course,

  No, I'm not specifying any curves. I'm just disallowing certain ones.

> so we can interoperate, but why rule out particular instantiations a

   Because patents tend to be written generally to cover more than
"particular instantiations".

> as well as special TLS ciphers saying it can use EC. This is ridiculous.

  I don't think you understand how TLS works. It is necessary to convey
the particular curve to use and it is necessary to convey the information
required by the key exchange (i.e. the commitment).

  Again, if you have a _specific_ comment on how to do this differently,
I'm all ears. As was mentioned in the last call notice, "[t]he document
needs particular attention paid to the integration of this mechanism
into the TLS protocol." You seem to imply you have some way to
improve its integration into the TLS protocol. So instead of questioning
my ability or expressing your personal dissatisfaction that not enough
papers were written and years passed before this draft was written
maybe you can make a concrete and relevant comment to help improve
things. If not, then thank you for your most impressive soliloquy on
Edwards curves, Weierstrauss, big discriminants and the ever-fearful
"what will Joux do next".

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 3 Dec 2013 14:51:49 -0800 (PST)

Hi Rene,

> on the CFRG dragonfly protocol on that list.

  Already done. Thank you for your comments there, they will improve the
document. As you noted there your "review comments… *strictly* apply
to the latest CFRG draft only; the related TLS draft will be dealt with
separately." So I'm glad these two are not linked in your mind.

> As far as I am concerned, my TLS WGLC comments still stand.

  So what would you like me to do about them? Please comment below.

>>    This has already been discussed in this thread by the way.

  Your curiosity on advantages dragonfly has over other exchanges is
not really a comment on the draft unless you are suggesting adding
such a section. Are you?

  Similarly, there is no statement of "specialness" in the draft so your
inability to determine its specialness is also not really anything to do
with something in the draft. Do you want a section on "specialness
considerations"? If so, can you point to any other similar types of
drafts/RFCs that have such a section?

>>    This suggestion has already been done.

  Indeed, this was done. The delta from -01 to -02 of the CFRG draft is
irrelevant to the draft under discussion here on this thread. There is no
LC on the IRTF draft but you can take that up with David and Kevin. There
are no changes possible to the draft under question regarding what the
CFRG is doing so I'm not sure how to resolve your comment.

>> is to avoid walking through a patent mine field.

  We seem to disagree on this. I view binary curves and those with a
co-factor > 1 as problematic so the limitation is a feature.

  If you would like to make a case on why avoiding a patent minefield
is not a good thing to do we can try and gauge WG consensus on the
issue.

>> would be no guarantee that each side arrived at the same element

  If this comment stands then explain what you'd like to see done to the
draft to address it. The technique is already deterministic and you seem to
want to remove non-determinism from it so I'm not sure what you're
looking for here.

  regards,

  Dan.

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 3 Dec 2013 14:59:20 -0800

On Tue, Dec 3, 2013 at 12:27 AM, Dan Harkins <[email-masked]> wrote:
> advantages over augmented PAKE schemes like TLS-SRP

Wait, what?

"Augmented PAKE" is of course better than "Balanced PAKE", as it
allows the server to store non-usable credentials.

TLS already has an "Augmented PAKE" - TLS/SRP (RFC 5054) which is
implemented in OpenSSL and elsewhere.

It's not used on the web, or widely, as the TLS layer is generally the
wrong place for user authentication (e.g. leaks username, terminated
at front-end machines without access to user credentials, etc).

However, what little demand exists for a TLS PAKE seems like it's
being adequately served by TLS-SRP.

Why is the WG considering another PAKE with worse properties (non-augmented)?

Trevor

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 3 Dec 2013 16:12:17 -0800 (PST)

>> advantages over augmented PAKE schemes like TLS-SRP

  Yes, well good morning to you too!

> allows the server to store non-usable credentials.

  This point was noted in the text you snipped in your response.

> implemented in OpenSSL and elsewhere.

  This was also mentioned in the text you snipped in your response.

> Why is the WG considering another PAKE with worse properties

  As has been discussed on the list, because it also has better
properties. And it has useful applications.

  A better question is, where have you been for the past 2 years?
You wait to question consideration of this draft not only after it's
been adopted as a working group item but also after WGLC has
closed on the draft!

  Dan.

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 3 Dec 2013 18:58:18 -0800

On Tue, Dec 3, 2013 at 4:12 PM, Dan Harkins <[email-masked]> wrote:
> properties.

What I can find you claiming is [1]:
"""
What’s wrong with SRP? Nothing, but...
 - Nice to have EC support
 - Finite cyclic group is not fixed for each user
"""

I can't see how it matters that an SRP user's password has a fixed
group.  And I don't think EC alone justifies this, given that:
 - it has weaker security properties than SRP (non-augmented)
 - it has an ad-hoc design still being subject to attacks (see Bodo's point)
 - TLS/SRP is already deployed and in use by the few people who care
about TLS PAKE

>   A better question is, where have you been for the past 2 years?

Reading this list.  The feedback has been almost entirely negative
since you first proposed it [2].  I haven't had much to add.

Trevor

[1] http://www.ietf.org/proceedings/83/slides/slides-83-tls-2.pdf
[2] http://www.ietf.org/mail-archive/web/tls/current/msg08208.html

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 3 Dec 2013 19:04:32 -0800

> [1] http://www.ietf.org/proceedings/83/slides/slides-83-tls-2.pdf

Fixing the reference:
[2]  http://www.ietf.org/mail-archive/web/tls/current/msg08162.html

Trevor

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 5 Dec 2013 12:45:40 +0100

Mohamad Badra <[email-masked]>:

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

That's something different from a password-authenticated key exchange,
though.  In your specs, the client sends the password to the server (in
encrypted form).  If the server isn't actually the legitimate party
expected by the client, this compromises the password.  So the client still
depends heavily on authenticating the server first.

In a *password-authenticated* key exchange, the client doesn't readily
compromise the password if an attacker poses as the server.  So the client
doesn't have to do the usual certificate-based check to authenticate the
server (although, depending on the specific scheme, you could optionally
still do that, to mitigate certain kinds of attacks) -- that's why it's
called "password-authenticated": authentication is inherently based on that
password.  All an attacker posing as the server should get is *one* single
attempt (per client-initiated connection) to guess the password; all the
server will learn, unless that guess happens to be correct, is that that
wasn't the right password.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 5 Dec 2013 12:48:51 +0100

Dan Harkins <[email-masked]>:

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.

Bodo

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 5 Dec 2013 17:36:25 +0400

> depends heavily on authenticating the server first.

Agree. The purpose was to enable client's password-based authentication to
server storing password in clear text or the password's hash ( e.g., LDAP
and EAP).

It cannot be used without a server-side certificate - at least for the
first connection - but if the client share a password with the server, the
public key of the server could be installed on the client host (i.e., as
with SSH), in which case the client will not depend on authenticating the
server during every session.

​Best regards,
Badra​

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Dec 2013 06:47:52 -0800

> discussion is that the protocol wasn't actually reviewed by the CFRG with

Bodo,

The TLS WG isn't chartered to evaluate cryptographic mechanisms, so
where there is some question we generally rely on CFRG for an opinion
as we recently did with Salsa, ChaCha, etc. [1].  (I know you know
this, but to state for the mailing list)

With that in mind, TLS-PWD was the first time we did that and as Joe
stated, we did have a verbal report back from the chair of the CFRG
that they considered it satisfactory. However, based on the present
discussion it's clear that a number of people have concerns about
the security of the underlying mechanism. One of the purposes of
Last Call is to flush out exactly this kind of objection, so that's
good, though I wish we'd caught this earlier. We're still working
on the CFRG interface, so hopefully we'll get better at that part.

Anything we standardize in this area really does need to have a clean
report back from the CFRG. It seems clear that that's not the case
here.

-Ekr
[As chair]

[1] http://www.ietf.org/mail-archive/web/tls/current/msg10221.html

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 5 Dec 2013 09:15:28 -0800 (PST)

> discussion is that the protocol wasn't actually reviewed by the CFRG with

  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.

  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.

The response to #2 is that lack of implementation of these other
protocols has been hampered by patents and TLS-pwd is not
patented (and the underlying dragonfly key exchange is not patented
either). Theoretically I think there are some elegant alternatives to
TLS-pwd but practically I don't think there are. Regardless though,
there is nothing stopping Rene and/or Watson from doing any work
on any other protocol they think should be advanced. Since I am not
their slave^H^H^H^H^Hgrad student I do not feel compelled to
throw away my work and write papers and wait years as has been
suggested.

(The little uptake in PAKE protocols in the IETF in the recent years is
the result of people following me around from EMU to IPsecme and
now to TLS and after I do the leg work and present a dragonfly-style
exchange someone else comes along and says "hey, me too").

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.

  To sum, there has been no demonstration of a flaw against the
dragonfly protocol, just some people unhappy that I don't live up
to their standards or that my views of what is important in a PAKE
protocol is not congruent to theirs.

  regards,

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 5 Dec 2013 09:41:17 -0800

I disagree with the summary of my position.
TlS-SRP is deployed and implemented now. It can be used freely by
everyone, because the patent is freely licensed.
It has been a part of the TLS standard for years.

There are PAKE protocols with security proofs. It is not unreasonable
to demand that a new PAKE meet the standard which existing
protocols have set. A ZKPK on a hash of the temporary Diffie-Hellman
key+the password is perfectly fine, but quite computation heavy.
But for the examined use case computation work isn't a problem:
embedded devices don't handle thousands of connections.

The history of authentication protocols is littered with protocols
believed secure by their creators which were flawed, only for
the flaws to be discovered years later. Wide-Mouth Frog, early
Kerberos, station-to-station protocol, the various Tor key exchanges,
etc. As a result it is reasonable to demand a proof of any new
protocol in this field, especially when once in the standard it will
take years
to remove if a problem is found.

Dragonfly isn't secure in the sense that there exists an algorithm
that carries out an offline guessing attack. I can't provide the
algorithm:
it depends on a bunch of numbers which are the discrete logarithms of
the various PKEs in the terminology of dragonfly. But it exists,
meaning that stating what it means for dragonfly to be secure is
beyond our current knowledge. (Hash functions suffer from this also,
but in practice this can be worked around) In particular, there are
some random oracles for which dragonfly is broken (namely ones which
jigger the point picking process).

Users depend (unwisely, given the history of this WG) on TLS to be
secure above all else. Arguing that the processes previously existing
in the WG has not provided this guarantee is arguing for increased
scrutiny, not less. Adding complexity to TLS has a cost in making
implementations larger and harder to audit, as well as introducing all
sorts of ways to have misconfiguration. We should only introduce
new options when they satisfy usecases existing ones do not.

What does Dragonfly offer over J-PAKE? What does Dragonfly offer over
SRP? Are these benefits worth losing the benefit of security proofs
and years of analysis? And why isn't J-PAKE suitable for your usecase?
Sincerely,
Watson Ladd

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 5 Dec 2013 10:01:56 -0800

> the former has been pointed out on this list and the CFRG list, the later

Yes, it has.  Bodo pointed out a security flaw.

> process that does not exist.

At Watson points out, times have changed and the bar is higher now.

Regarding PSK: It does not attempt to be a PAKE.  Bringing it up here
is irrelevant.

> 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

Additionally, developments such as Elligator and AugPAKE hold promise
for protocols that have both security proofs *and* no IPR encumbrance.

> and TLS-pwd is not

People like Tom Wu, Nikos, Quinn Slack, myself, and many others did
the "legwork" for a TLS PAKE years ago (TLS-SRP).  It was deployed in
several TLS libraries, some commercial products, and browser patches
were attempted.

We learned something very significant about TLS PAKE:  Almost no-one
wants it.  Providing usernames in the clear is an unacceptable leak of
information, and front-end TLS machines are rarely where sites wish to
perform user authentication.

> the benefits of one are not compelling then be happy you can

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.

> protocol is not congruent to theirs.

To sum:  TLS already has an ad-hoc PAKE which is serviceable for those
few application which want such a thing.  We don't need another one.

Trevor

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 5 Dec 2013 10:24:02 -0800 (PST)

> It has been a part of the TLS standard for years.

  Your conclusion (you disagree with my summary of your position) is
logically disconnected from your premise (I never stated that TLS-SRP
was not deployed or implemented). In other words, you are demonstrating
the red herring fallacy.

> and years of analysis? And why isn't J-PAKE suitable for your usecase?

  I think you are mistaken. No one is proposing that we lose the benefits
or security proofs behind deployed and implemented security protocols.
This is not a zero sum game.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 5 Dec 2013 10:40:36 -0800 (PST)

> 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.

> At Watson points out, times have changed and the bar is higher now.

  You are appealing to a process that does not exist.

> 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?

> for protocols that have both security proofs *and* no IPR encumbrance.

https://datatracker.ietf.org/ipr/2037/

> to do with architectural issues with the approach, which your draft

  You are free to not use this protocol as well if you do not find it
compelling.

  Dan.

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 5 Dec 2013 12:42:29 -0800

>   You should read the entire email before you respond to it. Like the

I did.  Bodo pointed out a security flaw, despite your attempts to spin it.

>   You are appealing to a process that does not exist.

The process for acquiring trust in new cryptographic algorithms is
widely understood to involve (A) rigorous security proofs, and (B)
succesfully withstanding years of cryptanalysis (particularly
important if lacking A).

You have neither.

> used with elliptic curves.

Not true, for example see Hamburg and Bernstein's Elligator 2 [1],
which could be used as the basis for a DH-EKE style PAKE.

>   You are free to not use this protocol as well if you do not find it

We should not standardize protocols which are inferior to existing
ones and to newer alternatives, have insufficient cryptographic
analysis, have no application, and have no support in the WG beside
the draft authors and the NSA [2].

I remain opposed.

Trevor

[1] https://eprint.iacr.org/2013/325.pdf
[2] http://www.ietf.org/mail-archive/web/tls/current/msg08371.html

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 5 Dec 2013 21:56:42 +0100

> the former has been pointed out on this list and the CFRG list, the later

Right, there's a difference between that (and good reasons to prefer
protocols that *have* been proven secure where those exist), but my main
point here was that there hasn't actually been a thorough protocol review
by the CFRG.

Bodo

---

From: Robert Ransom <[email-masked]>
Date: Thu, 5 Dec 2013 13:10:26 -0800

> which could be used as the basis for a DH-EKE style PAKE.

In particular, 2^255-21 factors as a product of two 128-bit numbers
(12405336376215349613*16478153705137396313 and
96110449917563*20607492579733193238707*11*13); it would be fairly easy
to build a Feistel-type block cipher operating between those two
subrings.  (There must be (at least) two natural points in the image
of the Elligator 2 map that could be excised from the set of permitted
public keys; I know there are for Elligator 1.)

(I'm not going to look for ways to split a large subset of 2^414 - 17 now.)

Robert Ransom

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 5 Dec 2013 13:13:05 -0800 (PST)

> which could be used as the basis for a DH-EKE style PAKE.

  Now THAT is an interesting alternative.

  But, alas, the benefit of doing that is uncompelling to you so I don't
know why you mention it. According to you the cryptographic difference
provided by EKE using Elligator public keys has nothing to do with the
architectural differences that you insist are behind the disinterest
(according to you) of PAKE protocols in TLS.

> the draft authors and the NSA [2].

  That is just pathetic FUD and a really lame smear. You should be
ashamed of yourself.

> I remain opposed.

  And you even would be opposed to alternatives you suggest instead
(see above). You helped out on TLS-SRP and are opposed to anyone
doing anything else. That is quite obvious.

  Dan.

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 6 Dec 2013 01:30:48 +0400

On Fri, Dec 6, 2013 at 12:42 AM, Trevor Perrin <[email-masked]> wrote:

> analysis, have no application,

How was your document betterthan PWD when you initially submitted
draft-taylor-tls-srp-00?​​ The only security analysis was made by the
authors of the paper on SRP.

and have no support in the WG beside
> the draft authors and the NSA [2].
I am not co-author, nor NSA, but I support this document.

Best regards,
Badra

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 5 Dec 2013 14:14:03 -0800

> (according to you) of PAKE protocols in TLS.

That's true.  I wouldn't support any PAKE for TLS without some new
interest from TLS implementors.

But if that interest existed, and a PAKE could be integrated into a
TLS handshake in a way that hides the client's username; is simple,
efficient, and secure; and is "state-of-art" relative to alternatives,
that could be worth considering.

>   That is just pathetic FUD and a really lame smear. You should be

I reviewed the TLS and CFRG mailing lists, and while I found a great
deal of criticism of this draft, the only positive feedback I could
find, prior to Mohamad, was from Kevin Igoe, NSA employee and CFRG
chair [1,2].  I presume Kevin also provided the "verbal report" to our
chairs that CFRG considers this satisfactory.

I find Kevin's enthusiasm strikingly at odds with other expert review
(compare [1,2] vs. this entire thread).  Furthermore, it's well-known
that Kevin's employer expends considerable resources to "Influence
policies, standards, and specification" for commercial cryptography to
make it more "tractable" to cryptanalysis [3].

In these lights, I find Kevin's feedback a source of concern.

Trevor

[1] http://www.ietf.org/mail-archive/web/tls/current/msg08371.html
[2] http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html
[3] http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=1&

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 5 Dec 2013 14:16:32 -0800

On Thu, Dec 5, 2013 at 1:30 PM, Mohamad Badra <[email-masked]> wrote:
> draft-taylor-tls-srp-00? The only security analysis was made by the authors
> of the paper on SRP.

I didn't submit the initial draft (David Taylor - 2001), nor invent
SRP (Tom Wu - 1998).

Regardless, that was a long time ago, when TLS had no PAKE, the patent
situation was trickier, SRP was state-of-the-art, and people wanted to
experiment with PAKE in the TLS handshake.

If the roles were reversed, and we were proposing TLS-SRP in 2013 when
Dragonfly had been adopted years earlier (and found to be largely
un-useful), we'd be met with the same skepticism.

Trevor

---

From: SeongHan Shin <[email-masked]>
Date: Fri, 6 Dec 2013 10:22:04 +0900

Dear all,

>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

-- 
------------------------------------------------------------------
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 : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : [email-masked]
------------------------------------------------------------------

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 5 Dec 2013 17:50:18 -0800 (PST)

> The patent of AugPAKE was granted in Feb. and April of 2013 from Japan and

  No, it doesn't say "any conforming implementation" period. It says:

         "[I]f this document...is adopted as an IETF standards
          track RFC, AIST is prepared to grant a non-exclusive
          royalty-free license for any conforming implementations
          of the adopted version (as an IETF standards track RFC)
          of this document."

So it has to be a standards track RFC. But even that's not really
true because it goes on to say:

         "Needless to say, this does not mean that all the claims
          and the contents in the patent application
          PCT/JP2009/062578 are covered with the non-exclusive
          royalty-free license."

So even if it was a standards track document, AIST reserves
the right to still go after people to whom it granted this
"royalty-free" license. Anyone who took such a license should
get, or get better, legal counsel.

  Dan.

---

From: SeongHan Shin <[email-masked]>
Date: Fri, 6 Dec 2013 11:03:15 +0900

Dear all,

It is clear from this IPR Disclosures:

The below means that AugPAKE can be used royalty-free, but other schemes in
the patent can not.

Best regards,
Shin

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 5 Dec 2013 18:24:59 -0800 (PST)

On Thu, December 5, 2013 6:03 pm, SeongHan Shin wrote:
> The below means that AugPAKE can be used royalty-free, but other schemes
> in the patent can not.
>

  No, what is says is that the "royalty-free" license does not necessarily
cover all the claims in the patent and anyone who implements it under
such a "royalty-free" license is still open to being sued by AIST.

  Maybe you should put a "Patent Infringement Considerations" section
in your draft to spell out exactly which claims are not covered by your
"royalty-free" license.

  Dan.

---

From: SeongHan Shin <[email-masked]>
Date: Fri, 6 Dec 2013 11:33:36 +0900

Dear Dan,

>           of the adopted version (as an IETF standards track RFC)

The statements in the IPR Disclosure was made by an attorney of AIST.
If you think differently, it is better to consult your attorney for its
clarity.

Best regards,
Shin

---

From: Watson Ladd <[email-masked]>
Date: Thu, 5 Dec 2013 23:24:03 -0800

>   You are appealing to a process that does not exist.
There is no set process for getting things through a WG. Checking
boxes will never make
up for a lack of substance. This argument seems to be that because we
made mistakes in
the past, we can't avoid making them in the future. The process you
seem to think applies
did not prevent RC4, implicit IVs, MAC-pad-encrypt, downgrade attacks,
or the parser complexity
responsible for many security vulnerabilities.

I don't see why demanding security reductions in some acceptable model
is so onus a requirement.
If it means we are unnecessarily conservative, I'm fine making that
tradeoff. If this means that
no changes to TLS get made because no one wants to do the work to get
me to approve, I'm fine with
that. We have a working TLS ecosystem right now for some definition of
"working", namely Suite B. We still
don't have secure code implementing TLS on all CPUs.
That took 20 years, and still isn't widespread. Jeopardising that is
not worth a yet another PAKE.
> https://datatracker.ietf.org/ipr/2037/
Just because one particular protocol is patented does not mean others aren't.
J-PAKE is going through the CFRG, works with ECC, and has a proof. Why couldn't
you use that instead? (yes, it does incur an additional round.)
You could use a key hiding authentication system and generate a key
from a password.
You can use any multiparty equality computation protocol.
All of these are more acceptable to us than something that doesn't
even have a formal
statement of security claims, let alone a proof. What do you mean that
Dragonfly is
secure? Because for many random oracles it isn't.
>   You are free to not use this protocol as well if you do not find it
The problem is that people faced with the choice of TLS-SRP and TLS-PWD
will not be aware of the relevant tradeoffs, and make the *wrong
choice*. The goal
of this WG is not to provide a choose your own adventure, where mistakes lead to
other people reading your passwords. There is tremendous pressure on TLS
implementations to implement objectively bad ideas that are part of
the standard,
and it is quite hard to get rid of them.

Take your financial institution, and see what gets negotiated with your browser.
And you want to give the people responsible for that more ways to
shoot themselves in the foot?

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 6 Dec 2013 02:00:52 -0800 (PST)

> Just because one particular protocol is patented does not mean others

  Who said otherwise? Certainly not me. But you sure got that straw man.
Good shooting!

  I was just responding to a statement that purported to mention an
unpatented protocol that not only is patented but also has a pretty nasty
licensing agreement.

> you use that instead? (yes, it does incur an additional round.)

  I have an idea, why don't you? Work that extra round into the TLS
protocol. Write up an Internet-Draft. Seriously. Please write this up. I
can't wait to see it.

> choice*.

  Ahh, the voice of inexperience….

  Yes, people do make bad decisions because they don't understand all
the nuances. In the real world what they do is something stupid like a
self-signed certificate ("just check 'OK', it's alright") followed by HTTP
digest authentication. That's the good one, sometimes they just do PAP
with a self-signed certificate. Or they use a PSK cipher suite with a
simple password. When this has been exposed these companies have
responded to me, "but we're using TLS so it's secure" or "we're using AES
so it's secure". The problem is not that these people you refer do not
know  how to choose between TLS-SRP and TLS-pwd, it is that they are
not given the opportunity to use either one.

  But there are other people who can, and want to, make the right choice.
Like using TLS-pwd with ECC to authenticate to an EST server so one can
parlay a simple password/code/phrase/key into a certificate with an
ECC public key-- instead of using a 1024-bit FFC group to certify a
384-bit ECC public key it makes sense to use the same ECC group for
authentication that is used to generate the certified public key. Or
people whose small embedded devices (where hardcoding large FFC
groups is out of the question) have rudimentary UIs that limit ones
choice of credential to something simple like a password and want
to use TLS-pwd to authenticate with a central server.

> The goal

  Oh, so what you're saying is that there is now tremendous pressure to
implement TLS-pwd (an "objectively bad idea" in your opinion)?  You might
want to get with Trevor. You guys seem to be at odds over that one.

> shoot themselves in the foot?

  My financial institution will not use TLS-pwd. It won't use TLS-SRP either.
TLS-pwd is not a universal, useful-for-all situations, cipher suite. It has
a very specific set of use cases for which it is applicable and financial
institutions are not one of them.

  Which isn't to say that there are no problems with the TLS connection to
my bank. I have no relationship with  the company whose CA is used by
my bank. I've never audited the processes they use with their CA, I don't
know their disaster recovery plan. I have never met any officers in the
company and have no reason to believe they are trustworthy and not
susceptible to some form of blackmail. So actually I have no reason to
trust the certificate presented by my bank signed by their CA when I
connect to my bank's server. But my browser trusts it for me because
some industry consortium that I am not a party to vouched for it. So
if you're worried about financial institutions and how browsers connect
to them I think you have bigger concerns that TLS-pwd.

  Dan.

---

From: CodesInChaos <[email-masked]>
Date: Fri, 6 Dec 2013 12:14:20 +0100

> the former has been pointed out on this list and the CFRG list, the later

How is using a password hash a hundred times weaker than md5crypt not
considered a security flaw?
Database compromises happen all the time, and forcing the server to
store a weakly hashed password
isn't acceptable IMO.

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 6 Dec 2013 08:42:24 -0800

> unpatented protocol that not only is patented but also has a pretty nasty

I disagree, AugPAKE's IPR declaration is reasonable.

One might wish that it covered broader uses, besides just
standards-track TLS implementations.

However, within that case, the terms are clearly "royalty-free".

Trevor

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 6 Dec 2013 10:29:22 -0800 (PST)

> considered a security flaw?

  It's not. A password hash that's 100x weaker than md5crypt would be a
security flaw.

> store a weakly hashed password

  You're absolutely right, that would not be acceptable.

  TLS-pwd uses HMAC-SHA256 with a 32 byte random key (salt) to
hash passwords that the server stores.

  Dan.

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 10 Dec 2013 16:45:50 +0000

Hi,

I only joined the conversation recently. Had a quick read of
http://tools.ietf.org/html/draft-ietf-tls-pwd-02 and have a question:

In a scenario where multiple users use the same password (group password):

What prevents a user (who knows the password) to impersonating the server
and mount a MITM between another user and the real server?

thanks & regards,

ralf

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 10 Dec 2013 09:01:35 -0800

> and mount a MITM between another user and the real server?

Hi Ralf,

I believe that's possible.

In the TLS PAKE described in RFC 5054 (TLS/SRP), the server may
additionally be authenticated via a server certificate.

Trevor

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 10 Dec 2013 14:06:53 -0800 (PST)

Hi Ralf,

> and mount a MITM between another user and the real server?

  Nothing prevents that. This protocol is not designed to support group
passwords. The password credential is assumed to be shared between
the client and the server only.

  regards,

  Dan.

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Wed, 11 Dec 2013 16:03:14 +0000

Hi,

I'm concerned that it will happen in practice: Same password for all users
to authenticate the server.

I feel that the risk should be mentioned under 'Security Considerations'.

"It should be noted that any user with the knowledge of the password can
impersonate the server and perform
a Man-in-the-middle attack against any other user who is using the same
password".

(Maybe some native english speaker can make this sound like Prince Charles
would say it.)

Comments welcome,

regards,

ralf

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 11 Dec 2013 08:34:40 -0800 (PST)

Hi Ralf,

> (Maybe some native english speaker can make this sound like Prince Charles

  I will add such a note to the Security Considerations, although I can't
guarantee it will sound like Prince Charles :-)

  thanks for your suggestion,

  Dan.