Subject: [Uta] updated I-Ds

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 13 Feb 2014 11:51:16 -0700

Yaron, Ralph, and I have updated our respective documents as follows:

1. draft-sheffer-uta-tls-attacks is in essence what used to be Section 2 
of draft-sheffer-tls-bcp

2. draft-sheffer-tls-bcp now focuses primarily on the recommendations

3. draft-saintandre-xmpp-tls now mostly points to draft-sheffer-tls-bcp

Please review the document set and let us know how things can be improved!

https://datatracker.ietf.org/doc/draft-sheffer-uta-tls-attacks/

https://datatracker.ietf.org/doc/draft-sheffer-tls-bcp/

https://datatracker.ietf.org/doc/draft-saintandre-xmpp-tls/

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Watson Ladd <[email-masked]>
Date: Thu, 13 Feb 2014 11:51:29 -0800

On Thu, Feb 13, 2014 at 10:51 AM, Peter Saint-Andre <[email-masked]> wrote:
> 1. draft-sheffer-uta-tls-attacks is in essence what used to be Section 2 of
> draft-sheffer-tls-bcp
>

Some notes: The first two drafts do not discuss certificate validation
or pinning, which are useful for browsers and special purpose apps.

The recommendation to employ 128-bit symmetric encryption is in
conflict with the substance of the DHE recommendation. The number
field sieve takes time L(1/3, 64/9). Currently a 530 bit prime can be
done effectively with 3 core years of sieving. This implies that a
1024 bit prime will take approximately 10.5 core years, and 2048 bits
15 core years. The linear algebra step is always cheaper than sieving
on custom hardware. Double check the arithmetic, but I think this is
right. By contrast an ECDLP solution over P256 would take 2^{128}
operations, which with a billion computers doing a trillion operations
a second would take longer than recorded human history.

Brainpool curve implementations currently are weaker than NIST curves
because of timing side channels.

Sincerely,
Watson Ladd
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

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

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Sun, 23 Feb 2014 12:18:07 +0000

Peter et al,
First, thanks a lot for investing the cycles before the deadline.
Inline are my comments and questions for clarification.
Looking forward to having a good discussion next week. Hopefully Yaron and Ralph will be able to join remotely.
Orit.

> -----Original Message-----
> From: Uta [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: Thursday, February 13, 2014 10:51 AM
> To: [email-masked]
> Subject: [Uta] updated I-Ds
> 
[OL] Looks good. My question to the list is to what extent having an RFC listing the known attacks is helpful? Should it include more detailed info for each attack?
What are our expectations from the scope of the intended RFC, who would like to contribute, and in what timeframe?

> 2. draft-sheffer-tls-bcp now focuses primarily on the recommendations
[OL] A great start!
A few thoughts and questions that come to mind:
- The title includes both TLS and DTLS. Per our AD's email from a few weeks ago, we should discuss how to proceed.
- It would be helpful to compile a list of additional aspects to be covered under Chapter 3 "Considerations" based on the list feedback and  f2f discussions next week.
- In 4.1 the statement that this document is not a profile in the sense of Sec.9 of RFC5246 is very important. It should be at the very top of the document ;-).
For improved readability, please,  consider to
- Combine 3.3 with 4 in terms of content and style (for example, as "Rationale" where appropriate).
- Keep "Security Considerations" to the minimum and incorporate the current "considerations" under the Recommendations topics
- Number the bullets for easier reference
One specific: In 3.3, "export-level" encryption might be an inappropriate term to be used by a standard, while the length examples are probably outdated.
 
> 3. draft-saintandre-xmpp-tls now mostly points to draft-sheffer-tls-bcp
[OL] I trust your knowledge about TLS with XMPP ;--) My comments are procedural only.
- Where would this draft belong to? To UTA or to XMPP since it is an active WG?
- Section 4.6 Unauthenticated Connections carefully and successfully avoids the "opportunistic encryption" terminology ;-) and introduces its own definitions... still an alignment will be needed  with whatever terminology the community decides to use going forward.

> Please review the document set and let us know how things can be
[OL] +1

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Feb 2014 19:46:29 +0000

Hi,

> - The title includes both TLS and DTLS. Per our AD's email from a few weeks ago, we should discuss how to proceed.
Commenting on one point only: I think including both in a generic 
document that applies to multiple protocols is fine. Personally, I don't 
think we need to recharter just for that.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 25 Feb 2014 15:54:59 -0500

On 02/13/2014 02:51 PM, Watson Ladd wrote:
> Currently a 530 bit prime can be done effectively with 3 core years of sieving.

do you mean "a 530 bit composite can be factored…" here?

the CADO-NFS team reports roughly 6 core-years for RSA-155, a 512-bit
number:

 http://cado-nfs.gforge.inria.fr/#feat

so that's in the same ballpark.  But:

> This implies that a 1024 bit prime will take approximately 10.5 core years, 
> and 2048 bits 15 core years. 

These are alarmingly short estimates, given the parallelizability of GNFS.

Recent work (also with CADO-NFS):

  http://maths-people.anu.edu.au/~bai/paper/rsa704.pdf

suggests 12 core years for polynomial selection for RSA-704, and 500 CPU
years for sieving.

Can you explain your estimate of 10.5 core years for RSA-1024 or 15 core
years for RSA-2048?

Regards,

	--dkg

---

From: Watson Ladd <[email-masked]>
Date: Tue, 25 Feb 2014 13:35:04 -0800

> do you mean "a 530 bit composite can be factored…" here?

No, I mean that a discrete logarithm in G_m modulo a 530 bit prime can be
computed in 3 core years of work.

This is different from RSA, but closely related. I looked up the record on
Wikipedia.
> Can you explain your estimate of 10.5 core years for RSA-1024 or 15 core

I redid the arithmetic and it looks like I was off/made a typo. Take
L(n)=c*e^{(log n)^a*(loglog n)^(1-a)} with a 1/3, figure out the constant,
and plug in the lengths.

Redoing it I get 8000 core years for DH modulo a 1024 bit prime and about 4
billion core years for 2048 bit prime.

The point is DHE with the 1024 bit prime is much weaker than other
algorithms being considered.
Sincerely,
Watson Ladd

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 25 Feb 2014 16:42:03 -0500

> billion core years for 2048 bit prime.

Thanks for clarifying.  This closer to what i was expecting.

> algorithms being considered.

Yes, agreed.  DHE-1024 needs to be deprecated.

	--dkg

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Feb 2014 22:40:37 +0000

> Yes, agreed.  DHE-1024 needs to be deprecated.

True. But I would hope UTA WG BCPs can be broadly
implemented without waiting for a massive upgrade
so its possible we could have to live with DH-1024.

Much better if that's only a niche or just gets fixed,
but that's the kind of trade off that needs to be
considered. And an important part of that trade off
is not between DH-1024 and RSA-2048, but rather
between PFS and non-PFS ciphersuites.

S.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 Feb 2014 10:43:05 +0200

The document recommends ECDHE over DHE, because DHE parameters cannot be 
negotiated and so some people will be stuck with DH-1024. See 
http://tools.ietf.org/id/draft-sheffer-tls-bcp-02.html#rfc.section.4.2

But for those people who cannot switch to ECDHE, the tradeoff is exactly 
between RSA-2048 and DH-1024. Stephen would recommend DH-1024 in this 
case, because the NSA can get at the server's private key and then, if 
you don't have PFS, you're hosed.

I would recommend RSA-2048 in this case, because DH-1024 can be broken 
today with commercially available compute power (buy a few Amazon extra 
large instances and let them run for a few months). Also, and this is a 
value judgment, I think the cryptographic break is a higher risk than 
wholesale theft of the private keys.

Thanks,
	Yaron

On 02/26/2014 12:40 AM, Stephen Farrell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQEcBAEBAgAGBQJTDRviAAoJEC88hzaAX42i6zIH/RVaXQWArXWBdga17SHXqvO7
> viQ1M3iTdNHmaROxdT+qAtt6OXK6eY20bG/QHFvZrUX+RW051LhbCh3WvztXyjfH
> BOI+VypROebsmDODi/bFU8JnP4BI8m0F9nsDQTv7QXqV+kG7Rf6nmX7Dru0n0/ad
> uTi1WAeTaFft7gKJMGp1enA9ruTP6BqfmcGG+6ejzS9D5bFNQjndTpmsLTLqKCVU
> XfO+DRd2F0t/SQVOgTGilxD31gDGlvJioNA4IXjd3PMi6+1BSFuLj10z+SaaTHCe
> +yjOVcz8Dg6HaY6PZwW+9o9UDS6Y8f/pnOMxSqy7D8I3sKwuyMJ/cHwM/ksStz4=
> =6IKl
> -----END PGP SIGNATURE-----
>

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Wed, 26 Feb 2014 12:11:09 +0000

How about documenting this kind of applicability considerations under a short "Rationale" paragraph for each choice?
That would be especially helpful for hard choices where there is a no clear winner
- in terms of implementation availability and/or
- it is determined by a deployment case

Orit.

> From: Uta [mailto:[email-masked]] On Behalf Of Yaron Sheffer
> Sent: Wednesday, February 26, 2014 12:43 AM
> To: Stephen Farrell; Daniel Kahn Gillmor; Watson Ladd
> Cc: [email-masked]
> Subject: Re: [Uta] updated I-Ds
>

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 Feb 2014 14:23:31 +0200

Hi Orit,

Each choice we make needs a rationale, for sure.

The question of where to put it (per paragraph, in a separate section, 
in a separate document) is mostly editorial. For us, having the 
rationale close to the decision is helpful. For the presumed audience 
(system architects, implementers) it's best if the rationale is 
separate, so that the essence of the document is as short as possible.

Thanks,
	Yaron