Subject: [Uta] WGLC on draft-ietf-uta-tls-bcp-06

From: Leif Johansson <[email-masked]>
Date: Fri, 24 Oct 2014 17:21:03 +0200

Folks,

This email starts a 2 week WGLC for draft-ietf-uta-tls-bcp-06. Please
provide your comments no later than Friday the 7th of November.

	Orit & Leif

---

From: Watson Ladd <[email-masked]>
Date: Fri, 24 Oct 2014 08:41:52 -0700

Section 1, penultimate paragraph, says TLS 1.3 will obsolete this
document. It's not clear why, especially given that TLS 1.3 is likely
to have a lengthy time to be adopted, and won't contain
recommendations for other versions.

Section 2, bullet 3 seems to include STMP. It's unclear if this is in
fact correct.

2.1. We have "They are not in the scope of this document. We discuss
them under.." which seems wrong to me.

7.4 doesn't explain what the checks are that are required on points,
referring instead to an IKE document.

These are very minor complaints.

On Fri, Oct 24, 2014 at 8:21 AM, Leif Johansson <[email-masked]> wrote:
> _______________________________________________
> 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: Leif Johansson <[email-masked]>
Date: Fri, 24 Oct 2014 17:50:55 +0200

> recommendations for other versions.

I guess the sentiment is "deployment of TLS 1.3 will obsolete this
document"...

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 24 Oct 2014 19:20:07 +0300

Hi Watson,

Please see below.

	Yaron

> Section 2, bullet 3 seems to include STMP. It's unclear if this is in

SMTP is used both for message submission and for server-to-server 
message relay. The document applies to the former, but probably not to 
the latter.

> them under.." which seems wrong to me.

Please explain what you mean here.

> referring instead to an IKE document.

As a co-author of both the current document and the cited IKE document, 
I believe such checks are way out of scope of a BCP. They are definitely 
needed, and there should be a standards track document describing them. 
You are welcome (I am not being cynical) to write one.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 24 Oct 2014 19:51:50 +0300

> provide your comments no later than Friday the 7th of November.

Should there be anything about ensuring that trust anchors are
properly validated? After all, path validation doesn't mean much
if there are trivial ways to bypass it.

There have been programs that do proper validation of names,
but:

1) Accept inapporiate self-signed certificates.
2) Accept any certificate signed by a "CA" (don't validate TAs).
3) Both 1 and 2 at once.

The set of apporiate trust anchors is obviously application-specific
and could even include EE certificates (or RFC 7250 RPKs).

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Fri, 24 Oct 2014 10:11:11 -0700

On Fri, Oct 24, 2014 at 9:20 AM, Yaron Sheffer <[email-masked]> wrote:
> SMTP is used both for message submission and for server-to-server message
> relay. The document applies to the former, but probably not to the latter.
>
>>

For something not in scope, we spend a lot of time talking about them.

> As a co-author of both the current document and the cited IKE document, I
> believe such checks are way out of scope of a BCP. They are definitely
> needed, and there should be a standards track document describing them. You
> are welcome (I am not being cynical) to write one.

That's going on the maybe pile. But I see your argument, despite many
implementations having these checks, and some not.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 24 Oct 2014 11:29:11 -0600

> On Oct 24, 2014, at 10:51 AM, Ilari Liusvaara <[email-masked]> wrote:
> 

Referencing RFC 5280 and RFC 6125 might be enough in this context.

Peter

---

From: Leif Johansson <[email-masked]>
Date: Fri, 24 Oct 2014 19:42:16 +0200

> Referencing RFC 5280 and RFC 6125 might be enough in this context.

Maybe stick that in the security considerations section?

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 26 Oct 2014 12:26:16 -0700

> provide your comments no later than Friday the 7th of November.

The following is split into three sections in decreasing order of importance.

--Paul Hoffman

*** Huge security issue ***

5.4:
   Rationale: because Diffie-Hellman keys of 1024 bits are estimated to
   be roughly equivalent to 80-bit symmetric keys, it is better to use
   longer keys for the "DHE" family of cipher suites.  Key lengths of at
   least 2048 bits are estimated to be roughly equivalent to 112-bit
   symmetric keys and might be sufficient for at least the next
   10 years.  See Section 5.5 for additional information on the use of
   modular Diffie-Hellman in TLS.

Earlier, the document points to RFC 3766 (thank you), and that document has different estimates than what the draft has here. From RFC 3766:
====================
   +-------------+-----------+--------------+--------------+
   | System      |           |              |              |
   | requirement | Symmetric | RSA or DH    | DSA subgroup |
   | for attack  | key size  | modulus size | size         |
   | resistance  | (bits)    | (bits)       | (bits)       |
   | (bits)      |           |              |              |
   +-------------+-----------+--------------+--------------+
   |     70      |     70    |      947     |     129      |
   |     80      |     80    |     1228     |     148      |
   |     90      |     90    |     1553     |     167      |
   |    100      |    100    |     1926     |     186      |
   |    150      |    150    |     4575     |     284      |
   |    200      |    200    |     8719     |     383      |
   |    250      |    250    |    14596     |     482      |
   +-------------+-----------+--------------+--------------+

5.1.  TWIRL Correction

   If the TWIRL machine becomes a reality, and if there are advances in
   parallelism for row reduction in factoring, then conservative
   estimates would subtract about 11 bits from the system security
   column of the table.  Thus, in order to get 89 bits of security, one
   would need an RSA modulus of about 1900 bits.
====================

That is, with a TWIRL correction, 1024-bit keys yield about 65 bits of equivalent strength, not the 80 listed in the draft. A 2048-bit key would give about 92 bits of strength.

Of course, the draft can refer to other documents that have happier estimates of strength for 1024-bit and 2048-bit keys, but that does not help the intended audience for this document.

*** Large issues ***

1:
   TLS 1.3, when it is standardized and deployed in the field,
   should resolve the current vulnerabilities while providing
   significantly better functionality.  It will very likely obsolete
   this document.
This is not correct. TLS 1.3 will only deal with a subset of the issues brought up in this draft, so it will not obsolete this draft. Further, it would only make this draft obsolete when it is universally deployed, which won't happen in our lifetimes. Proposed rewording:
   It is expected that the TLS 1.3 specification will resolve many of
   the vulnerabilities listed in this document. A system that deploys
   TLS 1.3 will have fewer vulnerabilities than TLS 1.2 or below. This
   document is likely to be updated after TLS 1.3 gets noticeable
   deployment.

2.1:
   o  Confidentiality: all (payload) communication is encrypted with the
      goal that no party should be able to decrypt it except the
      intended receiver.
Actually, all of the application-layer communication is encrypted, not just payloads. Proposed rewording:
   o  Confidentiality: all application-layer communication is encrypted with the
      goal that no party should be able to decrypt it except the
      intended receiver.

2.2:
   (indeed, often a server will not know whether a
   client might attempt authenticated or unauthenticated TLS)
A server can *never* tell whether a client validated the server's certificate. Proposed rewording:
   (indeed, a server cannot know whether a
   client might attempt authenticated or unauthenticated TLS)

4.2:
   o  In many application protocols, clients can be configured to use
      TLS even if the server has not advertised that TLS is mandatory or
      even supported (e.g., this is often the case in messaging
      protocols such as IMAP and XMPP).
What is "advertised" supposed to mean here? The above is certainly not true for STARTTLS-style protocols. If this is meant to cover protocols that use URI schemes that might or might not end is "s", those are not server advertisements. I'm not sure how to reword this because it is too unclear.

5.5:
   Rationale: Elliptic Curve Cryptography is not universally deployed
   for several reasons, including its complexity compared to modular
   arithmetic and longstanding IPR concerns.
If this document wants to spread the IPR FUD, please at least counter it with:
   (These concerns have generally been eliminated with the publication of RFC 6090.)

7.3:
   Forward secrecy (also often called Perfect Forward Secrecy or "PFS"
   and defined in [RFC4949])
... but then the draft refer to "PFS" instead of "forward secrecy". It would be better to use the more accurate term.

*** Editorial ***

2: s/WWW/web/

2.1:
   o  Authentication: an end-point of the TLS communication is
      authenticated as the intended entity to communicate with.  TLS
      enables authentication of one or both end-points in the
      communication.  Some TLS usage scenarios do not require
      authentication.  They are not in the scope of this document.  We
      discuss them under Section 2.2.
The last two sentences change from the positive to the negative in a confusing way. Maybe move those two sentences to their own unbulleted paragraph.

5.4:
   Where a
   client certificate is used, a third one is added.
To be clearer, that should be "...a third public key is used".

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 26 Oct 2014 23:22:59 +0200

Hi Paul,

Responding just to the first part of your mail:

The document is not advocating 1024-bit DHE. In Sec. 5.5 it lists it as 
the third best option, and explains why some deployers might be forced 
to use it even though "1024 bit modular DH parameters are generally 
considered insufficient at this time".

Re: the TWIRL correction (http://cs.tau.ac.il/~tromer/twirl/): 11 years 
on, I wonder why we still don't have any 1024-bit factorizations, given 
that the machine's cost should have gone down to around $100K (applying 
Moore's law and vigorous hand-waving).

Yes, we need to correct the bit-length estimate.

Thanks,
	Yaron

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 26 Oct 2014 14:56:39 -0700

On Oct 26, 2014, at 2:22 PM, Yaron Sheffer <[email-masked]> wrote:

> Re: the TWIRL correction (http://cs.tau.ac.il/~tromer/twirl/): 11 years on, I wonder why we still don't have any 1024-bit factorizations, given that the machine's cost should have gone down to around $100K (applying Moore's law and vigorous hand-waving).

There are many possible reasons, but I suspect that the best one is "working on post-TWIRL engines in secret is yielding good results". The fact that Shamir et. al. did their work in public does not mean that others will continue to do so.

> Yes, we need to correct the bit-length estimate.

Thank you.

--Paul Hoffman

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 27 Oct 2014 16:26:52 +0100

Yaron Sheffer wrote on 24.10.2014 18:20:

> As a co-author of both the current document and the cited IKE document, I believe such checks are way out of scope of a
> BCP. They are definitely needed, and there should be a standards track document describing them. You are welcome (I am
> not being cynical) to write one.
> 

Shouldn't the BSP at least specify the objective of these tests, i.e. group membership? Currently, the draft says
"should test the DH public key" which could be misleading.

-- 
Johannes

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 27 Oct 2014 17:31:03 +0200

> "should test the DH public key" which could be misleading.

Yes, it should.

Thanks,
	Yaron

---

From: Ralph Holz <[email-masked]>
Date: Mon, 27 Oct 2014 18:30:10 +0100

Hi Paul,

Yaron has already commented on a few points, I'll add some of my own.
Please find them inline.
​

> This is not correct. TLS 1.3 will only deal with a subset of the issues
> brought up in this draft, so it will not obsolete this draft. Further, it
> would only make this draft obsolete when it is universally deployed, which
> won't happen in our lifetimes. Proposed rewording:
I am not entirely sure what TLS 1.3 will bring or not. I am happy with
keeping this much more open-worded.

>       goal that no party should be able to decrypt it except the
That was indeed meant; your version is better.

>    client might attempt authenticated or unauthenticated TLS)
Yes, and we should use your version.

> What is "advertised" supposed to mean here? The above is certainly not
> true for STARTTLS-style protocols. If this is meant to cover protocols that
> use URI schemes that might or might not end is "s", those are not server
> advertisements. I'm not sure how to reword this because it is too unclear.
>
>
I am not sure here, either.

>    (These concerns have generally been eliminated with the publication of
I think it is safe so say that IPR discussions did have an effect on
deployment in the *past*, and that is probably what the document wanted to
say (after all, the current deployment is a result of actions that are now
in the past). Furthermore, I am not sure how many people know of the good
news that IPR is no longer a concern. The thing can be easily reworded by
making it "and IPR concerns, which, for the most part, have now been
resolved [RFC6090]". Note: IANAL.

> ... but then the draft refer to "PFS" instead of "forward secrecy". It
> would be better to use the more accurate term.
>
>
OK.

> 2: s/WWW/web/
Why? Is this an issue of "use only one version"? I find WWW to be the
clearer term, actually.

> The last two sentences change from the positive to the negative in a
> confusing way. Maybe move those two sentences to their own unbulleted
> paragraph.
>
>
ACK. This has also been mentioned by Watson (I think).

> To be clearer, that should be "...a third public key is used".
ACK.

Thanks for the review!

Ralph