Subject: [Uta] Barry Leiba's Discuss on draft-ietf-uta-tls-bcp-09: (with DISCUSS and COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Wed, 18 Feb 2015 16:16:43 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-uta-tls-bcp-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

One very simple point:

-- Section 2 --

   A number of security-related terms in this document are used in the
   sense defined in [RFC4949].

Terminology definitions need to be in normative references; 4949 should
be normative.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I don't want to make these a DISCUSS, but I would appreciate a
discussion:

-- Section 3.1.1 --
On the SHOULD NOTs here: Is there any reason one might violate them
*other than* that the other side doesn't support TLS 1.2 ?  If not, is it
worth saying that explicitly?  Is it even worth changing "SHOULD NOT
negotiate TLS version [x]" to "MUST NOT negotiate TLS version [x] unless
no higher version is available in the negotiation" ? 

How can I evaluate each of the following "SHOULD"s?  Why might I have a
good reason not to comply with each of them?:

-- Section 3.2 --

   o  When applicable, Web servers SHOULD use HSTS to indicate that they
      are willing to accept TLS-only clients.

-- Section 3.3 --

   Implementations and deployments SHOULD disable TLS-level compression
   ([RFC5246], Section 6.2.2).

-- Section 3.5 --

   TLS clients
   SHOULD apply the same validation policy for all certificates received
   over a connection, bind the master secret to the full handshake, and
   bind the abbreviated session resumption handshake to the original
   full handshake.

-- Section 4.2.1 --

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

For the above set of "SHOULD" questions, I'm looking for something in the
document that can help readers understand why these are not "MUST", and
when and why they might make an informed decision not to abide by them.

---

One other non-blocking comment; no discussion needed:

-- Section 3.1.2 --
Nit: "correlates to Version 1.2 of TLS 1.2" -- take out one of the "1.2"
?

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 18 Feb 2015 18:12:47 -0700

Hi Barry, thanks for the feedback. My comments inline (not coordinated 
with my co-authors, who are in far-off timezones).

> http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

Good point. We'll correct that in the revised I-D after tomorrow's telechat.

Yes, I think that's a much better way to express it.

> good reason not to comply with each of them?:

Those are always good questions to ask.

>        are willing to accept TLS-only clients.

Section 11.3 of RFC 6797 might provide a good reason (self-signed 
certificates) in some circumstances. Other than the relative youth of 
RFC 6797, I have not yet given more thought to other reasons.

(BTW, it strikes me now that the phrase "when applicable" perhaps 
provides unnecessary wiggle room.)

>     ([RFC5246], Section 6.2.2).

Because it's not yet clear to me that all application protocols using 
TLS or DTLS are subject to these compression-based attacks (at least, I 
have not yet seen analysis of all the many such protocols), personally I 
would hesitate at this time to say that all protocols MUST disable 
TLS-level compression.

>     bind the abbreviated session resumption handshake to the original

Some of those recommendations are not yet fully baked (e.g., binding the 
master secret to the full handshake is described in 
draft-ietf-tls-session-hash) or in the early stages of development 
(e.g., RFC 5746 does not explicitly apply to abbreviated handshakes and 
the triple-handshake authors say only that they propose to define a 
secure resumption indication extension along the lines of RFC 5746) so 
it is probably premature to say that they are best *current* practices.

>     whenever it is proposed, even if it is not the first proposal.

I think that one would be fine as MUST (notice, however, that it applies 
to a cipher suite that itself is a SHOULD).

> when and why they might make an informed decision not to abide by them.

Always a good idea.

> Nit: "correlates to Version 1.2 of TLS 1.2" -- take out one of the "1.2"

Noted.

Thanks again,

Peter

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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 18 Feb 2015 17:16:57 -0800

Thanks, Peter, for the quick response.  I'll hold the DISCUSS for now,
for clerical purposes pending a revised I-D.  On the "SHOULD"
explanations, thanks for the explanations, and it'd be great if some
version of them could get into the document.

Barry

On Wed, Feb 18, 2015 at 5:12 PM, Peter Saint-Andre - &yet
<[email-masked]> wrote:
> Hi Barry, thanks for the feedback. My comments inline (not coordinated with
> my co-authors, who are in far-off timezones).
>
> certificates) in some circumstances. Other than the relative youth of RFC
> 6797, I have not yet given more thought to other reasons.
>
> (BTW, it strikes me now that the phrase "when applicable" perhaps provides
> unnecessary wiggle room.)
>
>> -- Section 3.3 --
>>
> Because it's not yet clear to me that all application protocols using TLS or
> DTLS are subject to these compression-based attacks (at least, I have not
> yet seen analysis of all the many such protocols), personally I would
> hesitate at this time to say that all protocols MUST disable TLS-level
> compression.
>
>> -- Section 3.5 --
>>
>>     TLS clients
> draft-ietf-tls-session-hash) or in the early stages of development (e.g.,
> RFC 5746 does not explicitly apply to abbreviated handshakes and the
> triple-handshake authors say only that they propose to define a secure
> resumption indication extension along the lines of RFC 5746) so it is
> probably premature to say that they are best *current* practices.
>
>> -- Section 4.2.1 --
>>
> I think that one would be fine as MUST (notice, however, that it applies to
> a cipher suite that itself is a SHOULD).
>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 18 Feb 2015 18:51:35 -0700

> version of them could get into the document.

Yes, we'll formulate some text for the revised I-D. Thanks again for the 
careful review.

Peter

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 19 Feb 2015 17:41:55 +0100

Hi,

> would hesitate at this time to say that all protocols MUST disable

At this point it does not hurt to have it a MUST either, right? Are
there any serious implications for implementors or deployed applications
if we have TLS-compression as `MUST be disabled` in the document?

> to a cipher suite that itself is a SHOULD).

+1.

Aaron

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 19 Feb 2015 10:03:48 -0700

Barry, following up, here is some proposed text (again, not yet 
coordinated with my co-authors).

> On 2/18/15 5:16 PM, Barry Leiba wrote:

<snip/>

> provides unnecessary wiggle room.)

OLD

NEW
    o  Web servers SHOULD use HSTS to indicate that they are willing to
       accept TLS-only clients, unless they are deployed in such a way
       that using HSTS would in fact weaken overall security (e.g., it
       can be problematic to use HSTS with self-signed certificates, as
       described in Section 11.3 of [RFC6797]).

> would hesitate at this time to say that all protocols MUST disable

OLD

NEW
    In order to help prevent compression-related attacks (summarized in
    Section 2.6 of [RFC7457]), implementations and deployments SHOULD
    disable TLS-level compression ([RFC5246], Section 6.2.2), unless the
    application protocol in question has not been shown to be open to
    such attacks.

> it is probably premature to say that they are best *current* practices.

OLD
    To counter the Triple Handshake attack, the recommended
    countermeasures from [triple-handshake] are adopted: TLS clients
    SHOULD apply the same validation policy for all certificates received
    over a connection, bind the master secret to the full handshake, and
    bind the abbreviated session resumption handshake to the original
    full handshake.  In some usages, the most secure option might be to
    refuse any change of certificates during renegotiation.

NEW
    To counter the Triple Handshake attack, the recommended
    countermeasures from [triple-handshake] are adopted: TLS clients
    SHOULD apply the same validation policy for all certificates received
    over a connection, SHOULD bind the master secret to the full
    handshake (one emerging approach is documented in
    [I-D.ietf-tls-session-hash]), and if possible SHOULD bind the
    abbreviated session resumption handshake to the original full
    handshake (although no standardized method for this has been defined
    as yet).  Although some of these methods are still under development,
    those who implement and deploy TLS are advised to watch for further
    improvements in these technologies.  If none of these countermeasures
    are available, the most secure option is to refuse any change of
    certificates during renegotiation.

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 19 Feb 2015 10:08:15 -0700

> if we have TLS-compression as `MUST be disabled` in the document?

Personally I would like to hear from some of the communities using DTLS 
before I would be comfortable with a MUST here.

Peter

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

---

From: Barry Leiba <[email-masked]>
Date: Thu, 19 Feb 2015 10:01:31 -0800

> Barry, following up, here is some proposed text (again, not yet coordinated
> with my co-authors).

Nice text all 'round; thanks.

>    application protocol in question has not been shown to be open to

Do you want "has not been shown to be open to such attacks", or "has
been shown not to be open to such attacks" ?

Barry

---

From: Watson Ladd <[email-masked]>
Date: Thu, 19 Feb 2015 10:08:37 -0800

> > Barry, following up, here is some proposed text (again, not yet
coordinated
> been shown not to be open to such attacks" ?

I strongly prefer the second. We shouldn't need live demos to convince us
of issues.

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 19 Feb 2015 11:52:47 -0700

> been shown not to be open to such attacks" ?

Yes, that is superior.

Peter

---

From: Ralph Holz <[email-masked]>
Date: Fri, 20 Feb 2015 10:10:37 +1100

Hi,

> if we have TLS-compression as `MUST be disabled` in the document?
+1 - I never felt comfortable with compression being decided by the
underlying layer and not the application itself.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 19 Feb 2015 18:08:08 -0700

Oops, send from the wrong email address.

-------- Forwarded Message --------
Subject: Re: [Uta] Barry Leiba's Discuss on draft-ietf-uta-tls-bcp-09: 
(with DISCUSS and COMMENT)
Date: Thu, 19 Feb 2015 18:07:07 -0700
From: Peter Saint-Andre <[email-masked]>
To: Ralph Holz <[email-masked]>, Aaron Zauner <[email-masked]>
CC: Peter Saint-Andre - &yet <[email-masked]>, [email-masked] 
<[email-masked]>, Barry Leiba <[email-masked]>, The IESG 
<[email-masked]>

> underlying layer and not the application itself.

The thing is, I don't think we know. What about, say CoAP or SRTP or
DCCP over DTLS? Do we really have enough information at this moment to
say that *all* application protocols using TLS or DTLS must not use
compression? In the absence of a complete survey, I'd still lean toward
a (strong) should.

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 19 Feb 2015 19:28:22 -0700

<snip/>

>     certificates during renegotiation.

The authors have been discussing this text. The problem is that some of 
these recommendations are not yet deployable, and we have strenuously 
avoided any forward-looking statements (no matter how tempting) in favor 
of recommendations that can be considered current practices.

Thus I would propose the following text:

    The most secure option for countering the Triple Handshake attack is
    to refuse any change of certificates during renegotiation.  In
    addition, TLS clients SHOULD apply the same validation policy for all
    certificates received over a connection.  The [triple-handshake]
    document suggests several other possible countermeasures, such as
    binding the master secret to the full handshake (see
    [I-D.ietf-tls-session-hash]) and binding the abbreviated session
    resumption handshake to the original full handshake.  Although the
    latter two techniques are still under development and thus do not
    qualify as current practices, those who implement and deploy TLS are
    advised to watch for further development of appropriate
    countermeasures.

Peter

---

From: Barry Leiba <[email-masked]>
Date: Thu, 19 Feb 2015 20:38:00 -0800

Looks nice.  Thanks for working this out.

b

On Thursday, February 19, 2015, Peter Saint-Andre - &yet <[email-masked]>
wrote:

> avoided any forward-looking statements (no matter how tempting) in favor of
> recommendations that can be considered current practices.
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 19 Feb 2015 18:07:07 -0700

Peter