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

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 03 Nov 2014 18:39:43 -0700

On 10/24/14, 11:42 AM, Leif Johansson wrote:
> On 2014-10-24 19:29, Peter Saint-Andre wrote:
>>
>>> On Oct 24, 2014, at 10:51 AM, Ilari Liusvaara <[email-masked]> wrote:
>>>
>>>> On Fri, Oct 24, 2014 at 05:21:03PM +0200, Leif Johansson wrote:
>>>>
>>>> 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.
>>>
>>>
>>> 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.
>>
>> Referencing RFC 5280 and RFC 6125 might be enough in this context.
>>
>
> Maybe stick that in the security considerations section?

I suggest adding the following paragraph at the end of Section 7.1:

    Host name validation typically applies only to the leaf "end entity"
    certificate.  Naturally, in order to ensure proper authentication in
    the context of the PKI, application clients need to verify the entire
    certification path in accordance with [RFC5280] (see also [RFC6125]).

Peter

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 03 Nov 2014 18:48:08 -0700

On 10/24/14, 10:20 AM, Yaron Sheffer wrote:

> On 10/24/2014 06:41 PM, Watson Ladd wrote:
>>
>> Section 2, bullet 3 seems to include STMP. It's unclear if this is in
>> fact correct.
>
> 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.

Well, the recommendations here apply to server-to-server communication 
for SMTP (and XMPP for that matter) in cases where the servers employ 
authenticated TLS. Although as Viktor points out such cases are not 
universal, they do happen, so I see no reason to categorically exclude 
server-to-server communication.

>> These are very minor complaints.

That's good to hear.

Peter

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 03 Nov 2014 18:49:28 -0700

On 10/24/14, 11:11 AM, Watson Ladd wrote:
> On Fri, Oct 24, 2014 at 9:20 AM, Yaron Sheffer <[email-masked]> wrote:
>>
>>> 2.1. We have "They are not in the scope of this document. We discuss
>>> them under.." which seems wrong to me.
>>
>>
>> Please explain what you mean here.
>
> For something not in scope, we spend a lot of time talking about them.

That's because unauthenticated TLS and opportunistic encryption have 
been a source of considerable discussion in the WG. :-)

Peter

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 03 Nov 2014 21:02:29 -0700

On 10/26/14, 1:26 PM, Paul Hoffman wrote:
> On Oct 24, 2014, at 8:21 AM, Leif Johansson <[email-masked]> wrote:
>
> 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.

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

I propose:

Peter

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 03 Nov 2014 21:03:20 -0700

I propose:

    o  In many application protocols, clients can be configured to use
       TLS no matter whether the server offers TLS during a protocol
       exchange or advertises support for TLS (e.g., through a flag
       indicating that TLS is required).  Application clients SHOULD use
       TLS by default, and disable this default only through explicit
       configuration by the user.

Peter

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 03 Nov 2014 21:05:37 -0700

> Earlier, the document points to RFC 3766 (thank you), and that document has different estimates than what the draft has here. From RFC 3766:

Paul, would the following text be more accurate?

    Rationale: For various reasons, in practice DH keys are typically
    generated in lengths that are powers of two (e.g., 2^10 = 1024 bits,
    2^11 = 2048 bits, 2^12 = 4096 bits).  Because a DH key of 1228 bits
    would be roughly equivalent to only an 80-bit symmetric key
    [RFC3766], it is better to use keys longer than that for the "DHE"
    family of cipher suites.  A DH key of 1926 bits would be roughly
    equivalent to a 100-bit symmetric key [RFC3766] and a DH key of 2048
    bits 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.

    As noted in [RFC3766], correcting for the emergence of a TWIRL
    machine would imply that 1024-bit DH keys yield about 65 bits of
    equivalent strength and that a 2048-bit DH key would yield about 92
    bits of equivalent strength.

    Servers SHOULD authenticate using at least 2048-bit certificates.

Your corrections are very much welcome.

Peter

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Nov 2014 07:49:15 -0800

>      configuration by the user.

Thanks, that's much clearer!

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Nov 2014 07:51:53 -0800

>   Servers SHOULD authenticate using at least 2048-bit certificates.

That's OK. I wish we could use stronger words about TWIRL (since I would be flabbergasted if one hadn't been created, and surprised if it hadn't been improved on), but I think that's all we can say while being evidence-based.

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Tue, 4 Nov 2014 08:25:03 -0800

> That's OK. I wish we could use stronger words about TWIRL (since I would be flabbergasted if one hadn't been created, and surprised if it hadn't been improved on), but I think that's all we can say…

Since RFC3766 has been published, the Factorization Factory has been
tried on Cunningham numbers, RSA-512 is factorizable on hobbyist
computers, and graphics cards have helped make the NFS faster. I don't
think this is the right document or right WG, but we should look again
at RSA key sizes to make sure we aren't missing anything.

In particular batched factorization of RSA-1024 keys is likely to
reduce the cost per key significantly.

Sincerely,
Watson Ladd

>
> --Paul Hoffman
> _______________________________________________
> 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