Subject: [Uta] Brief summary of the UTA WG meeting @IETF 91, Honolulu

From: "Orit Levin (LCA)" <[email-masked]>
Date: Wed, 12 Nov 2014 02:01:58 +0000

Brief summary of the UTA WG meeting @IETF 91, Honolulu
Tuesday, Nov 11, 2014

https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/
The new version incorporating all comments from the LC is available as -07. Short one week last call starts from today. All are encouraged to double check that their concerns and feedback have been addressed.
  
https://datatracker.ietf.org/doc/draft-newman-email-deep/
Adopted and will be resubmitted as a new WG ID. Rename "assurance" to "confidentiality". Ross and Sean will review the pinning mechanism. Keep the email certificates draft separate for now. Other open issues to be further investigated and discussed on the list.

https://datatracker.ietf.org/doc/draft-martin-authentication-results-tls/
Perceived as a useful tool including for the inter-domain use cases.  Expressed concerns are related to privacy and insufficient semantics of the recorded authentication details. The author will continue working on the individual draft. The author, Chris Newman, with other volunteers will write an (additional) draft focusing on the broader meaning/semantics of the inter-domain authentication.

https://datatracker.ietf.org/doc/draft-popov-token-binding/ and
https://datatracker.ietf.org/doc/draft-balfanz-https-token-binding/
Perceived as a very much needed approach. Defines a complicated system with many moving parts. HTTP is not a single application to benefit from it. Another would be Email with SAML. Strong sense that a dedicated new WG (preferably in the Security Area) needs to be established to make this infrastructural work finally happen. This is for the ADs to address.
 
"TLS Fallback Dance"
Daniel Kahn Gillmor with a group of volunteers (~5) will write an initial draft documenting known fallback use cases and the existing techniques to deal with them. Tentative goals include sharing common knowledge and educating the community about the pitfalls of this approach. 

Leif & Orit.

---

From: Brian Smith <[email-masked]>
Date: Tue, 11 Nov 2014 20:10:16 -0800

> o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246].
>
>      Rationale: TLS 1.0 (published in 1999) does not support many
>      modern, strong cipher suites.

I think that the lack of a per-record IV for CBC-based cipher suites
is a more serious issue. Also, I think the fact that the TLS 1.0
specification does not say " The receiver MUST check this padding and
MUST use the bad_record_mac alert to indicate padding errors." is
another more serious problem.

> o  Implementations MAY negotiate TLS version 1.1 [RFC4346].
>
>      Rationale: TLS 1.1 (published in 2006) is a security improvement
>      over TLS 1.0, but still does not support certain stronger cipher
>      suites.

The rationale SHOULD NOT for TLS 1.0 is that it doesn't support many
modern, strong cipher suites. But, the set of cipher suites supported
by TLS 1.1 is the same, or approximately so.

>    o  Implementations MUST support, and prefer to negotiate, TLS version
>      1.2 [RFC5246].

I suggest clarifying this as "Implementations MUST support TLS 1.2,
and MUST prefer to negotiate TLS 1.2 over earlier versions of TLS."
If/when TLS 1.3 or later versions are ready, it probably wouldn't be
good to still prefer TLS 1.2.

Section 3.1.3 "Fallback to Lower Versions" is unclear: Does it apply
to the standard, "secure," type of version rollback that is protected
by the TLS handshake, or does it apply to the non-secure fallback that
the TLS_FALLBACK_SCSV is designed to protect.

>   o  Ticket keys MUST be changed regularly, e.g., once every week, so
>      as not to negate the benefits of forward secrecy (see Section 7.3
>      for details on forward secrecy).
>
>   o  Session ticket validity SHOULD be limited to a reasonable duration
>      (e.g., 1 day), for similar reasons.

IMO, session ticket keys should be rotated at about half the frequency
that session tickets are invalidated. So, if you're recommending
session tickets last no more than one day, then session ticket keys
should be rotated every two days, at a minimum.

>   To counter the Triple Handshake attack, we adopt the recommendation
>   from [triple-handshake]: TLS clients SHOULD ensure that all
>   certificates received over a connection are valid for the current
>   server endpoint, and abort the handshake if they are not.

TLS clients MUST always ensure that the server's end-entity
certificate is valid for the server's identity on every handshake.
Also, that wasn't really the issue with triple handshake for most
implementations. The issue that most implementations had with triple
handshake was that they did certificate verification for
renegotiations too late in the handshake, after they'd already sent
private data using the keys negotiated during the renegotiation. For
example, Firefox did the certificate verification before sending any
secret information under the new keys, so it wasn't vulnerable, but
MSIE and Chrome (IIUC) waited until the renegotiation handshake was
finished, which was after they'd sent private information using the
new keys. So, IMO this whole section needs improvement.

>   o  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
>
>   o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>
>   o  TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>
>   o  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

I generally agree with these recommendations, but I think it is
inappropriate to recommend that clients support
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 or
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 at this time. Too many servers
only have 1024-bit or smaller(!!!) DHE keys, and there's no way for
the client to negotiate a minimum DHE key strength yet. Mozilla's data
for the Firefox web browser [1] shows that in the most recent release,
97% of handshakes that use TLS_DHE_* cipher suites use a 1024 bit key
and 2% of handshakes that use TLS_DHE_* cipher suites use
512-bit(!!!!!) keys. Approximately 0% of connections that negotiate
TLS_DHE_* cipher suites use a key DHE size that meets the minimum 112
bit security level that the document is attempting to acheive.

>    Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the
>    first proposal to any server, unless they have prior knowledge that
>    the server cannot respond to a TLS 1.2 client_hello message.

The team that implements NSS decided that it is better to suggest
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ahead of
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Also, Google Chrome often
proposes ChaCha20-Poly1305 cipher suites ahead of
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. I believe that these are
reasonable and even good policies, so I think that the above text
should be rewritten in such a way that NSS and Chrome's behavior meets
the requirements.

> Servers SHOULD prefer this cipher suite whenever it is proposed, even
> if it is not the first proposal.

This is not a good suggestion, for similar reasons. Many (most)
servers, when given the choice, will prefer
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 over
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for performance reasons.

>    This document is not an application profile standard, in the sense of
>    Section 9 of [RFC5246].  As a result, clients and servers are still
>    REQUIRED to support the mandatory TLS cipher suite,
>    TLS_RSA_WITH_AES_128_CBC_SHA.

A BCP defining cipher suite recommendations should not have a higher
level of requirement for TLS_RSA_WITH_AES_128_CBC_SHA than it has for
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, at least. I think it is OK to just
say that the TLS specification was wrong to mandate
TLS_RSA_WITH_AES_128_CBC_SHA, or don't mention it at all.

>   With regard to PKIX certificates, servers SHOULD support OCSP and
>   OCSP stapling, including the OCSP stapling extension defined in
>   [RFC6961], as a best practice given the current state of the art and
>   as a foundation for a possible future solution.

Please also say that servers SHOULD support the original stapling
mechanism, the certificate status request extension defined in
RFC6066, section 8. In practice, no clients support the RFC6961
mechanism, and that lack of support is partly intentional and unlikely
to change soon. Also, some browsers are working on new revocation
schemes that they feel make RFC6066 irrelevant for them, but where
RFC6066 is likely to remain relevant. Accordingly, it is fine to
recommend servers support RFC6961 but it is even more critical that
they support RFC6066.

Cheers,
Brian

[1] http://telemetry.mozilla.org/#filter=release%2F33%2FSSL_KEA_DHE_KEY_SIZE_FULL

     Here is the key, directly from the source code of Firefox:

                       bits <   512 ?  1 : bits ==   512 ?  2
                     : bits <   768 ?  3 : bits ==   768 ?  4
                     : bits <  1024 ?  5 : bits ==  1024 ?  6
                     : bits <  1280 ?  7 : bits ==  1280 ?  8
                     : bits <  1536 ?  9 : bits ==  1536 ? 10
                     : bits <  2048 ? 11 : bits ==  2048 ? 12
                     : bits <  3072 ? 13 : bits ==  3072 ? 14
                     : bits <  4096 ? 15 : bits ==  4096 ? 16
                     : bits <  8192 ? 17 : bits ==  8192 ? 18
                     : bits < 16384 ? 19 : bits == 16384 ? 20
                     : 0;

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 25 Nov 2014 20:38:40 -0700

> another more serious problem.

Noted.

> by TLS 1.1 is the same, or approximately so.

You make a good point. I'd be fine with SHOULD NOT for TLS 1.1 but I 
would like to know what other WG participants (and my co-authors) think 
before changing the document.

> good to still prefer TLS 1.2.

I expect that this BCP will be obsoleted by another BCP once TLS 1.3 is 
published and implemented and deployed.

But your suggestion is acceptable to me.

> the TLS_FALLBACK_SCSV is designed to protect.

Speaking only for myself, I don't think the authors differentiated 
between *how* you might get to TLS 1.0 or SSLv3 - only that you end up 
there at all.

In any case TLS_FALLBACK_SCSV is probably too new for us to recommend it 
as a best *current* practice.

> that session tickets are invalidated.

I don't have strong opinions on the time relationship here.

> So, if you're recommending

Thanks for pointing out the weaknesses here.

> bit security level that the document is attempting to acheive.

Do I understand correctly that you would recommend the ECDHE ciphers but 
not the DHE ciphers? Or would you recommend some other DHE ciphers?

> should be rewritten in such a way that NSS and Chrome's behavior meets

The authors will discuss this amongst themselves to see what we think is 
reasonable. Naturally we also look to the WG for feedback!

> TLS_RSA_WITH_AES_128_CBC_SHA, or don't mention it at all.

I don't know if RFC 5246 was *wrong*, but the situation on the ground 
has changed since 2008.

> recommend servers support RFC6961 but it is even more critical that

We've had another proposal for text on these points, so the authors will 
take a closer look.

Brian, thanks for your detailed review.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 26 Nov 2014 09:04:21 +0100

> Speaking only for myself, I don't think the authors differentiated between
> *how* you might get to TLS 1.0 or SSLv3 - only that you end up there at all.
>

Not that I'd necessarily disagree with that conclusion, but disabling SSL
3.0 entirely everywhere is much newer than the SCSV :-)

You might want to consider a non-normative reference to the
TLS_FALLBACK_SCSV draft (so that implementors will look at its current
status).

My main complaint with the content of this section of
draft-ietf-uta-tls-bcp-06, though, is that "fallback" should be spelt "fall
back" when used as a verb. The one-word form ("fallback") is correct for
the noun.

Bodo

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 26 Nov 2014 09:55:15 +0000

Hi Peter,

On 26 Nov 2014, at 03:38, Peter Saint-Andre - &yet <[email-masked]> wrote:

> I don't know if RFC 5246 was *wrong*, but the situation on the ground has changed since 2008.

I was wondering about the above as well. I think your document is updating MTI or at least narrowing down recommended choices, and CBC_SHA is not one of them. So deleting the two sentences quoted above is the best.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 Nov 2014 20:57:25 +0200

> I was wondering about the above as well. I think your document is updating MTI or at least narrowing down recommended choices, and CBC_SHA is not one of them. So deleting the two sentences quoted a…

Hi Alexey,

We are not defining MTI, we are recommending which cipher suites to 
negotiate. MTI (the bare minimum required for protocol interoperability) 
unfortunately remains that old cipher suite.

And (for those who enjoy procedural nitpicking), the meaning of "MUST" 
in a BCP is different from its meaning in a protocol definition.

Thanks,
	Yaron