From nobody Wed Oct 1 00:53:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAAA1A884A for ; Wed, 1 Oct 2014 00:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz4droHQjYUn for ; Wed, 1 Oct 2014 00:53:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1FDA1A8828 for ; Wed, 1 Oct 2014 00:53:51 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s917WnhK004950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 1 Oct 2014 03:32:49 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s917Wk0b015744 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2014 03:32:48 -0400 Message-ID: <1412148765.2628.4.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Michael StJohns Date: Wed, 01 Oct 2014 09:32:45 +0200 In-Reply-To: <542B2C80.7010903@nthpermutation.com> References: <542988C5.8050307@nthpermutation.com> <542B2C80.7010903@nthpermutation.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TYk79eF2pm6JHh6j6P1nJc7iojY Cc: "tls@ietf.org" Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 07:53:53 -0000 On Tue, 2014-09-30 at 18:19 -0400, Michael StJohns wrote: > On 9/30/2014 4:28 PM, Martin Thomson wrote: > > On 29 September 2014 09:28, Michael StJohns wrote: > >> Question: Is there absolutely no requirement for TLS1.3 integrity only > >> cipher suites? > > If you believe that integrity-only modes are valuable, you could > > propose an AEAD formulation that does not provide confidentiality. > > That's fairly trivial to do with an AEAD construction: just move > > everything under the AD part. > > To be a bit pedantic - that's not actually how you would do it. TLS > treats the user data as non-AD data. There is no provision in the > protocol for moving everything from encryption to AAD only. > > You could define an AEAD cipher such as NULL_HMAC_SHA256_AEAD could work > if you wanted integrity only - it's too bad we can't just use the > existing integrity only suites. It's not simply too bad, it is unnecessary work, and additional bloat to implementations which will have to carry two versions of the same ciphersuite. One that is valid for TLS 1.2 and prior, and another that will be valid for TLS 1.3 and later. Since SSL 3.0 is yet still in use we can expect this duplication (of code and bugs) to last at least 15 years. The benefit of this duplication is some "niceness" that will be observed in the TLS 1.3 protocol as everything will be marked as AEAD, but this "niceness" has no cryptographic value (the TLS 1.2 construction with cipher and MAC is authenticated encryption). Hence, instead of simplifying implementations, the AEAD-only move will add more code into implementations, duplicate code, increasing the number of potential bugs, and adding no value. regards, Nikos From nobody Wed Oct 1 09:36:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47C91ACE28 for ; Wed, 1 Oct 2014 09:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHAQooHkjACE for ; Wed, 1 Oct 2014 09:36:15 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9F91ACE7D for ; Wed, 1 Oct 2014 09:36:14 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id w8so511155qac.23 for ; Wed, 01 Oct 2014 09:36:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=Mv5v3jzlRfEGuqZrLMhVYbmFbADSx0/alwBDwIB+btY=; b=YB4G05/GhwQ3LpbvYaJzfUXI+Ln9aXxBZzKca0oUtRRe30jJ/G/9uMzQUe/WQ4WLJ9 RR5ofalKH2Dq/Rhjyd+Imcu30A1THW/swI7KGeewDyc/yvA0DOWKpFkAtZ1kWbhxnaTK zL4fc1nPIW9HNzhmWtqbSKLSNEKrL7y72lCIfBGJDN2PR+wVjAMI6l/t6yStcEl1G6kv Wx5J3iMgOk9OIFydr5xM9zFYm20JDjWUdrYGFsPSsLkTmuSiXpzRAx1eCqyHURQ0e9ME McMSVJv2Fq3p1m9oH0PW28GNXzxefL12OplEzoBVCT3KnQ26rtD1STgUHnExHtDKC7mY D8vQ== X-Gm-Message-State: ALoCoQnDuf1Pcm3u4Bgp0IjK4XitstZHntk0H9cR7qd7f5QlxblPYmUjTLSX03LFuq8SOb+mEb8C X-Received: by 10.140.84.11 with SMTP id k11mr88109520qgd.75.1412181373759; Wed, 01 Oct 2014 09:36:13 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:226:5d8b:d39a:536a:43ec? ([2601:a:2a00:226:5d8b:d39a:536a:43ec]) by mx.google.com with ESMTPSA id z7sm1026537qal.19.2014.10.01.09.36.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Oct 2014 09:36:13 -0700 (PDT) Message-ID: <542C2D85.7000705@nthpermutation.com> Date: Wed, 01 Oct 2014 12:36:21 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: tls@ietf.org References: <542988C5.8050307@nthpermutation.com> <44A2498B-D0CB-415C-A1D8-2E362FD8BDF0@cisco.com> <542B450C.5010304@cs.tcd.ie> In-Reply-To: <542B450C.5010304@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------050805060704060206040903" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LlNhyV89qbaM0ANJuVhCjUt6HRA Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 16:36:18 -0000 This is a multi-part message in MIME format. --------------050805060704060206040903 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 9/30/2014 8:04 PM, Stephen Farrell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hiya, > > On 30/09/14 22:23, Joseph Salowey (jsalowey) wrote: >> [Joe] I see your point, but its not within our current scope to >> design for this. > IMO Joe is fully correct. This WG has repeatedly dealt with > proposals of many kinds for standardising MiTM attacks on TLS > and has repeatedly rejected that functionality. And should it > ever be in favour while I'm the irresponsible AD, I'll be > asking for the complete analysis of the impact of that on > the literally hundreds of other IETF specifications (not to > mention non-IETF specs and running code) that depend on TLS > and implicitly on TLS not enabling a MiTM. I've raised this > point in response to the last 3 or maybe 4 (I've lost count > sadly) proposals to MiTM TLS and have yet to get a substantive > response. Hi Stephen - Sorry, but this is a complete mis-statement of the problem. 1) There are places where "someone" requires the disclosure of the confidentiality key of traffic transiting a specific network, or point. That's just reality. How that is done is not a TLS protocol issue. 2) _*Nowhere in any of the emails (or at least the in the email thread started by me) has there been a suggestion to "standardize MiTM attacks on TLS" .*__* This is somewhat fear mongering.*_ 3) TLS1.3 has exacerbated the problem of (1) by specifying AEAD as its sole cryptographic model because of: a) There are no viable integrity only AEAD cipher suites defined which could be used to satisfy (1) b) Since the only defined AEAD cipher suites couple the integrity key with the encryption key, it is impossible to reveal only the encryption key (thereby defeating the principle of least privilege). E.g. the command key is shared by more than two entities. 4) In a number of TLS cases that I'm aware of, the most important characteristic is mutual authentication (or at least sender/controller authentication), as TLS is used as a bearer service for command and control. Confidentiality is simply a "nice to have". That's the observed characteristic for most of the smart grid stuff, and I would expect that it will be similar for most of the IoT stuff. The key piece here is that using TLS1.3 actually weakens the security guarantees (protection of the control channel) given the real world constraints of confidentiality key escrow/release. For me this was an "unintended consequence" of the AEAD decision and one I didn't realize until I encountered a new requirement for (1). Note: I think (1) is a bad choice in pretty much all cases, but that I don't get to decide that, I just have to design systems that can be sold to customers that require it. > > This seems to me to be just another in this series of attempts > to legitimise such MiTMs, albeit in this case as a comment on > an already establish bit of WG consensus. (The MiTM part is > the suggestion that different keys be established with those > for confidentiality being "revealed.") The implication that "different keys be established" is something new in TLS is absurd. TLS1.3 makes changes that remove functionality and capabilities that have been in the protocol from the beginning. Making sure that the "unintended consequences" from those removals are actually intended seems to me to be no more than due diligence. As I said in my original message, the default for designers is going to be to fall back to TLS1.2, or use other IETF security protocols or build a proprietary protocol for such designs. That may be just fine. > > Yes, I know that there are deployments that do MiTM TLS. Yes, > I know that there are some people who say that is required > for some definition of required. (There are also those who > claim doing so is anathema, so the existence of an argument > is not in itself convincing.) I would ask however that those > making the MiTM argument please set that out clearly as the > change that it would represent to current IETF consensus > documents such as RFCs 2804 and the pretty recent 7258 and > others. But first try establish IETF consensus on your MiTM > principle. That (establish the principle first) would seem > to me to be the proper order required for such a change. What "change" are you talking about? By the way, RFC 7258 - you mention it above - has this: > Making > networks unmanageable to mitigate PM is not an acceptable outcome, > but ignoring PM would go against the consensus documented here. An > appropriate balance will emerge over time as real instances of this > tension are considered. This is somewhat different than considering all concerns resolved as you seem to imply above. From the customer's POV, (1) above is both a network management issue and possibly a legal compliance issue. They may own the network, and the traffic transiting it may mostly be machine-to-machine. The issues you (since you wrote 7258) raised with respect to PM are not broadly applicable to the privacy of a light switch or a sluice dam. I'd say that counts as a "real instance". I asked two questions in my original email: > Question: In light of the above, should we revisit the AEAD-only > decision for TLS1.3? > > > Question: Is there absolutely no requirement for TLS1.3 integrity > only cipher suites? The primary decision to remove AEAD was NOT because it made passive monitoring more difficult, but because it simplified the design of the protocol AND ensured proper integrity protection over records. The integrity only suites were a mostly unmourned casualty of that decision. I'm not aware of any earlier discussion on the subject I raised in this thread. I'm also not aware that anyone has proposed a change - we're just talking here to figure out whether or not we missed something critical in making that decision. So what exactly is the problem with this discussion? Mike > > S. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUK0UMAAoJEC88hzaAX42ikfUIAJxdIBnNfQaZWjczMiz68Jsw > +LUzR4xsPn4nosJAsUWoGEOQI6yP8aj90qPdYMEF5tYORVtdhrDtfjy9Lkl25884 > 9xep6ug86ya0JHlWmVdcjfH1gg9MIFw0MgH8XqENagCcYzXfpoCmJ6njVwimqROS > ZuZnTV+Fa9Offx95d3eZUY1fbe9kAPD18ClXry9J0CbDxxeKWumTLIz/egSGNv1q > kFokSJbyRmmzMBEVlUb/iY+Hx8zbqSnwR0n+BiyKIrvWiUn3ZWw5KT9HVoFuBZZS > 4czdFaWp9//J7GdJGZg5xz5LLBzeBB6VlFjjVNwiHXoFjswJBjgEuOf5yJQPEEQ= > =k+r4 > -----END PGP SIGNATURE----- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------050805060704060206040903 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 9/30/2014 8:04 PM, Stephen Farrell wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hiya,

On 30/09/14 22:23, Joseph Salowey (jsalowey) wrote:

[Joe] I see your point, but its not within our current scope to
design for this.

IMO Joe is fully correct. This WG has repeatedly dealt with
proposals of many kinds for standardising MiTM attacks on TLS
and has repeatedly rejected that functionality. And should it
ever be in favour while I'm the irresponsible AD, I'll be
asking for the complete analysis of the impact of that on
the literally hundreds of other IETF specifications (not to
mention non-IETF specs and running code) that depend on TLS
and implicitly on TLS not enabling a MiTM. I've raised this
point in response to the last 3 or maybe 4 (I've lost count
sadly) proposals to MiTM TLS and have yet to get a substantive
response.

Hi Stephen -

Sorry, but this is a complete mis-statement of the problem.

1) There are places where "someone" requires the disclosure of the confidentiality key of traffic transiting a specific network, or point.  That's just reality.  How that is done is not a TLS protocol issue.

2) Nowhere in any of the emails (or at least the in the email thread started by me) has there been a suggestion to "standardize MiTM attacks on TLS" .  This is somewhat fear mongering.

3) TLS1.3 has exacerbated the problem of (1) by specifying AEAD as its sole cryptographic model because of:
     a) There are no viable integrity only AEAD cipher suites defined which could be used to satisfy (1)
     b) Since the only defined AEAD cipher suites couple the integrity key with the encryption key, it is impossible to reveal only the encryption key (thereby defeating the principle of least privilege).  E.g. the command key is shared by more than two entities.

4) In a number of TLS cases that I'm aware of, the most important characteristic is mutual authentication (or at least sender/controller authentication), as TLS is used as a bearer service for command and control.  Confidentiality is simply a "nice to have".   That's the observed characteristic for most of the smart grid stuff, and I would expect that it will be similar for most of the IoT stuff.

The key piece here is that using TLS1.3 actually weakens the security guarantees (protection of the control channel) given the real world constraints of confidentiality key escrow/release.  For me this was an "unintended consequence" of the AEAD decision and one I didn't realize until I encountered a new requirement for (1).

Note:  I think (1) is a bad choice in pretty much all cases, but that I don't get to decide that, I just have to design systems that can be sold to customers that require it.


This seems to me to be just another in this series of attempts
to legitimise such MiTMs, albeit in this case as a comment on
an already establish bit of WG consensus. (The MiTM part is
the suggestion that different keys be established with those
for confidentiality being "revealed.")

The implication that "different keys be established" is something new in TLS is absurd.  TLS1.3 makes changes that remove functionality and capabilities that have been in the protocol from the beginning.  Making sure that the "unintended consequences" from those removals are actually intended seems to me to be no more than due diligence. 

As I said in my original message, the default for designers is going to be to fall back to TLS1.2, or use other IETF security protocols or build a proprietary protocol for such designs.  That may be just fine. 



Yes, I know that there are deployments that do MiTM TLS. Yes,
I know that there are some people who say that is required
for some definition of required. (There are also those who
claim doing so is anathema, so the existence of an argument
is not in itself convincing.) I would ask however that those
making the MiTM argument please set that out clearly as the
change that it would represent to current IETF consensus
documents such as RFCs 2804 and the pretty recent 7258 and
others. But first try establish IETF consensus on your MiTM
principle. That (establish the principle first) would seem
to me to be the proper order required for such a change.

What "change" are you talking about?

By the way, RFC 7258 - you mention it above -  has this:
 Making
   networks unmanageable to mitigate PM is not an acceptable outcome,
   but ignoring PM would go against the consensus documented here.  An
   appropriate balance will emerge over time as real instances of this
   tension are considered.
This is somewhat different than considering all concerns resolved as you seem to imply above.

From the customer's POV, (1) above is both a network management issue and possibly a legal compliance issue.  They may own the network, and the traffic transiting it may mostly be machine-to-machine.  The issues you (since you wrote 7258) raised with respect to PM are not broadly applicable to the privacy of a light switch or a sluice dam.  I'd say that counts as a "real instance".

I asked two questions in my original email:
Question:  In light of the above, should we revisit the AEAD-only decision for TLS1.3?


Question:  Is there absolutely no requirement for TLS1.3 integrity only cipher suites?

The primary decision to remove AEAD was NOT because it made passive monitoring more difficult, but because it simplified the design of the protocol AND ensured proper integrity protection over records. The integrity only suites were a mostly unmourned casualty of that decision.

 I'm not aware of any earlier discussion on the subject I raised in this thread.   I'm also not aware that anyone has proposed a change  - we're just talking here to figure out whether or not we missed something critical in making that decision.

So what exactly is the problem with this discussion? 

Mike




S.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUK0UMAAoJEC88hzaAX42ikfUIAJxdIBnNfQaZWjczMiz68Jsw
+LUzR4xsPn4nosJAsUWoGEOQI6yP8aj90qPdYMEF5tYORVtdhrDtfjy9Lkl25884
9xep6ug86ya0JHlWmVdcjfH1gg9MIFw0MgH8XqENagCcYzXfpoCmJ6njVwimqROS
ZuZnTV+Fa9Offx95d3eZUY1fbe9kAPD18ClXry9J0CbDxxeKWumTLIz/egSGNv1q
kFokSJbyRmmzMBEVlUb/iY+Hx8zbqSnwR0n+BiyKIrvWiUn3ZWw5KT9HVoFuBZZS
4czdFaWp9//J7GdJGZg5xz5LLBzeBB6VlFjjVNwiHXoFjswJBjgEuOf5yJQPEEQ=
=k+r4
-----END PGP SIGNATURE-----

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--------------050805060704060206040903-- From nobody Wed Oct 1 09:48:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2853A1ACE2C for ; Wed, 1 Oct 2014 09:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MT-PuAMnzKgs for ; Wed, 1 Oct 2014 09:48:00 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id EB88C1A1A9D for ; Wed, 1 Oct 2014 09:47:59 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E3F474753F; Wed, 1 Oct 2014 16:47:58 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id D7A894753E; Wed, 1 Oct 2014 16:47:58 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub7.dfw01.corp.akamai.com [172.27.25.73]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id B2F8880044; Wed, 1 Oct 2014 16:47:58 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub7.dfw01.corp.akamai.com ([172.27.25.73]) with mapi; Wed, 1 Oct 2014 11:47:58 -0500 From: "Salz, Rich" To: Michael StJohns , "tls@ietf.org" Date: Wed, 1 Oct 2014 11:47:57 -0500 Thread-Topic: [TLS] AEAD only for TLS1.3 revisit Thread-Index: Ac/dldghcZam609tSH645K7o54QnsgAACbqw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7B6B@USMBX1.msg.corp.akamai.com> References: <542988C5.8050307@nthpermutation.com> <44A2498B-D0CB-415C-A1D8-2E362FD8BDF0@cisco.com> <542B450C.5010304@cs.tcd.ie> <542C2D85.7000705@nthpermutation.com> In-Reply-To: <542C2D85.7000705@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7B6BUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ch2rV3XG1C8UcOkl0awzNSjWkUo Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 16:48:01 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7B6BUSMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't understand why you can't sell those customers TLS 1.2. Algebraically, I view TLS 1.3 =3D TLS 1.2 + various_predefined_extensions - some_= crypto_mechanisms + epsilon Is there something so important in that epsilon? Or is it just a case of "w= e must have the latest"? -- Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7B6BUSMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= I don’t understand why you can’t sell those customers TL= S 1.2.

 

Algebraically, I view

       =          TLS 1.3 =3D TLS 1.2 + vari= ous_predefined_extensions – some_crypto_mechanisms + epsilon

 

Is there something so important in that epsilon? Or i= s it just a case of “we must have the latest”?

 

-- 

Principal Security Engineer, Akamai Technologies

<= p class=3DMsoNormal>IM: rsalz@jabber.me Twitter: RichSalz

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7B6BUSMBX1msgcorp_-- From nobody Wed Oct 1 10:13:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0D01A1A92 for ; Wed, 1 Oct 2014 10:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF3ieRJMz1yW for ; Wed, 1 Oct 2014 10:13:22 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594011A1A89 for ; Wed, 1 Oct 2014 10:13:08 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so690487qcw.31 for ; Wed, 01 Oct 2014 10:13:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=r04yBsO1C/BJ5oGcnvGicIe0ZdODnuIMt2lQM98CLcE=; b=mfYSwTZUPmsJ3tLx69b3ySiR+jwActqsHxMvK6t8mDOLEkXpavQn/NMPfghcQhHsoX DDgveQTpkhNKyzFGX2ubXKahJQU1kJKoF71ufyCrOFLgia3cFSXzDOUe85B0TxaQjfDO e/7tQbgVi3Ec37lkPEULugWX0hJR18cqWFJwvtAHTyYitABqw0YBlyFU3JXttVifp/Ns uO/NRllf0r96O7GEukh1NlPOmO0Y1Aa116vO7XZk4oNOqATJhOodV4Dv9DjWwZnXyNs/ mesr8LLmk6rLEJI1dfNTh3rwnY2xnbIGc15JVYAl8EkScD4iIqDiis/hgMLUMT7l2/j2 6bIw== X-Gm-Message-State: ALoCoQmlNItwyasRdHzD/MREs9qRF23XHdta5WKM6ZlYD2N6xiv46QV7Eo7UJFnGSUva2QE7cQQJ X-Received: by 10.224.64.199 with SMTP id f7mr77807168qai.9.1412183587261; Wed, 01 Oct 2014 10:13:07 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:226:5d8b:d39a:536a:43ec? ([2601:a:2a00:226:5d8b:d39a:536a:43ec]) by mx.google.com with ESMTPSA id e9sm1081610qgd.46.2014.10.01.10.13.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Oct 2014 10:13:06 -0700 (PDT) Message-ID: <542C362A.4010802@nthpermutation.com> Date: Wed, 01 Oct 2014 13:13:14 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Salz, Rich" , "tls@ietf.org" References: <542988C5.8050307@nthpermutation.com> <44A2498B-D0CB-415C-A1D8-2E362FD8BDF0@cisco.com> <542B450C.5010304@cs.tcd.ie> <542C2D85.7000705@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7B6B@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7B6B@USMBX1.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------000302020504070102070104" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NDNXqhwyDc0X67tbLJu3ZjR2s_0 Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 17:13:24 -0000 This is a multi-part message in MIME format. --------------000302020504070102070104 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 10/1/2014 12:47 PM, Salz, Rich wrote: > > I don’t understand why you can’t sell those customers TLS 1.2. > > Algebraically, I view > > TLS 1.3 = TLS 1.2 + various_predefined_extensions – > some_crypto_mechanisms + epsilon > > Is there something so important in that epsilon? Or is it just a case > of “we must have the latest”? > > -- > > Principal Security Engineer, Akamai Technologies > > IM: rsalz@jabber.me Twitter: RichSalz > Hi Rich - TLS1.0 and 1.1 are "obsolete" for some value of obsolete. Once TLS1.3 is published, TLS1.2 will also be obsolete. That's as much reality as marketing and that causes problems with customers doing check box requirements. They say "TLS" and they mean "TLS, the latest and greatest" and explaining why you're offering TLS1.2 becomes a painful and sometimes business losing proposition. In your equation above, with respect to this thread only, the actual problem is not the " + epsilon" but the "- some_crypto_mechanisms" which took away all the mechanisms where the integrity key can be isolated from the encryption key. Trying to define new AEAD mechanisms that provide this capability *AND* make it in to sufficient commercial stacks becomes an interesting problem (and frankly a great deal of work in TLS1.3 that's not necessary in TLS1.2). We may end up with TLS1.2, or with another IETF security protocol (IPSEC?) or even with something proprietary. The discussion really is about how we're making a number of structural changes to TLS in the TLS1.3 draft. Some of them have interesting and possibly unintended consequences (cf the discussion on encrypting the handshake with respect to encrypting the SNI extension; or the discussion about doing the hash of the handshake mixin with key derivation interacting badly with the desire for 1rtt); this particular change had an unintended consequence that didn't come to light (at least for me) until I got a specific request and tried to figure out how to satisfy it. Later, Mike --------------000302020504070102070104 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 10/1/2014 12:47 PM, Salz, Rich wrote:

I don’t understand why you can’t sell those customers TLS 1.2.

 

Algebraically, I view

                TLS 1.3 = TLS 1.2 + various_predefined_extensions – some_crypto_mechanisms + epsilon

 

Is there something so important in that epsilon? Or is it just a case of “we must have the latest”?

 

-- 

Principal Security Engineer, Akamai Technologies

IM: rsalz@jabber.me Twitter: RichSalz

 


Hi Rich -

TLS1.0 and 1.1 are "obsolete" for some value of obsolete.  Once TLS1.3 is published, TLS1.2 will also be obsolete.  That's as much reality as marketing and that causes problems with customers doing check box requirements.  They say "TLS" and they mean "TLS, the latest and greatest" and explaining why you're offering TLS1.2 becomes a painful and sometimes business losing proposition.

In your equation above, with respect to this thread only, the actual problem is not the " + epsilon" but the "- some_crypto_mechanisms" which took away all the mechanisms where the integrity key can be isolated from the encryption key.  Trying to define new AEAD mechanisms that provide this capability *AND* make it in to sufficient commercial stacks becomes an interesting problem (and frankly a great deal of work in TLS1.3 that's not necessary in TLS1.2).

We may end up with TLS1.2, or with another IETF security protocol (IPSEC?) or even with something proprietary.  

The discussion really is about how we're making a number of structural changes to TLS in the TLS1.3 draft.  Some of them have interesting and possibly unintended consequences (cf the discussion on encrypting the handshake with respect to encrypting the SNI extension; or the discussion about doing the hash of the handshake mixin with key derivation interacting badly with the desire for 1rtt); this particular change had an unintended consequence that didn't come to light (at least for me) until I got a specific request and tried to figure out how to satisfy it. 

Later, Mike

--------------000302020504070102070104-- From nobody Wed Oct 1 10:36:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F2D1A1A7D for ; Wed, 1 Oct 2014 10:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcWWAymiedIB for ; Wed, 1 Oct 2014 10:36:40 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id EEB181A1A79 for ; Wed, 1 Oct 2014 10:36:39 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 88BFD1022400A; Wed, 1 Oct 2014 10:36:39 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 1 Oct 2014 10:36:39 -0700 (PDT) Message-ID: In-Reply-To: <542C362A.4010802@nthpermutation.com> References: <542988C5.8050307@nthpermutation.com> <44A2498B-D0CB-415C-A1D8-2E362FD8BDF0@cisco.com> <542B450C.5010304@cs.tcd.ie> <542C2D85.7000705@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7B6B@USMBX1.msg.corp.akamai.com> <542C362A.4010802@nthpermutation.com> Date: Wed, 1 Oct 2014 10:36:39 -0700 (PDT) From: "Dan Harkins" To: "Michael StJohns" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2ye9n3jGXOnvDSDtRohrhYSa3Sc Cc: "tls@ietf.org" Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 17:36:41 -0000 Hi Mike, On Wed, October 1, 2014 10:13 am, Michael StJohns wrote: > On 10/1/2014 12:47 PM, Salz, Rich wrote: >> >> I don’t understand why you can’t sell those customers TLS 1.2. >> >> Algebraically, I view >> >> TLS 1.3 = TLS 1.2 + various_predefined_extensions – >> some_crypto_mechanisms + epsilon >> >> Is there something so important in that epsilon? Or is it just a case >> of “we must have the latest”? >> >> -- >> >> Principal Security Engineer, Akamai Technologies >> >> IM: rsalz@jabber.me Twitter: RichSalz >> > > Hi Rich - > > TLS1.0 and 1.1 are "obsolete" for some value of obsolete. Once TLS1.3 > is published, TLS1.2 will also be obsolete. That's as much reality as > marketing and that causes problems with customers doing check box > requirements. They say "TLS" and they mean "TLS, the latest and > greatest" and explaining why you're offering TLS1.2 becomes a painful > and sometimes business losing proposition. > > In your equation above, with respect to this thread only, the actual > problem is not the " + epsilon" but the "- some_crypto_mechanisms" which > took away all the mechanisms where the integrity key can be isolated > from the encryption key. Trying to define new AEAD mechanisms that > provide this capability *AND* make it in to sufficient commercial stacks > becomes an interesting problem (and frankly a great deal of work in > TLS1.3 that's not necessary in TLS1.2). Such an AEAD mechanism has already been defined. RFC 5297 specifies AES in SIV mode. SIV takes a single key but it is of the "double wide" variety where the first half is for the integrity check key and the second half is the encryption key. So it's possible to isolate one half from the other assuming that the PRF that generated the double wide key prevents inferring anything about the first half from knowledge of the second half (I believe that will be the case for TLS 1.3). SIV is a perfectly valid AEAD mechanism and is part of the RFC 5116 registry. You'd just need to specify it as a TLS1.3 cipher suite. It would be very regrettable if SIV became known as the "escrowed AEAD mode" especially as it has other highly desirable properties, like not requiring a counter and being robust in the presence of counter misuse, if one is provided. On the other hand, it's likely that the people requiring this kind of snooping are some of the very same people that really dislike SIV mode (and oppose its adoption in standards) so maybe this would be justice of the poetic kind. Be that as it may, I think SIV solves your problem. regards, Dan. > We may end up with TLS1.2, or with another IETF security protocol > (IPSEC?) or even with something proprietary. > > The discussion really is about how we're making a number of structural > changes to TLS in the TLS1.3 draft. Some of them have interesting and > possibly unintended consequences (cf the discussion on encrypting the > handshake with respect to encrypting the SNI extension; or the > discussion about doing the hash of the handshake mixin with key > derivation interacting badly with the desire for 1rtt); this particular > change had an unintended consequence that didn't come to light (at least > for me) until I got a specific request and tried to figure out how to > satisfy it. > > Later, Mike > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Oct 1 10:57:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809CD1A1B0C for ; Wed, 1 Oct 2014 10:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYvg1qm8tA3L for ; Wed, 1 Oct 2014 10:57:50 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F051A1AED for ; Wed, 1 Oct 2014 10:57:50 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id BBAB94001; Wed, 1 Oct 2014 20:57:47 +0300 (EEST) Date: Wed, 1 Oct 2014 20:57:47 +0300 From: Ilari Liusvaara To: Michael StJohns Message-ID: <20141001175747.GA14447@LK-Perkele-VII> References: <542988C5.8050307@nthpermutation.com> <44A2498B-D0CB-415C-A1D8-2E362FD8BDF0@cisco.com> <542B450C.5010304@cs.tcd.ie> <542C2D85.7000705@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7B6B@USMBX1.msg.corp.akamai.com> <542C362A.4010802@nthpermutation.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <542C362A.4010802@nthpermutation.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TarX8Cswl9yYWhM93cvSwpI-hYU Cc: "tls@ietf.org" Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 17:57:52 -0000 On Wed, Oct 01, 2014 at 01:13:14PM -0400, Michael StJohns wrote: > On 10/1/2014 12:47 PM, Salz, Rich wrote: > > > In your equation above, with respect to this thread only, the actual problem > is not the " + epsilon" but the "- some_crypto_mechanisms" which took away > all the mechanisms where the integrity key can be isolated from the > encryption key. Trying to define new AEAD mechanisms that provide this > capability *AND* make it in to sufficient commercial stacks becomes an > interesting problem (and frankly a great deal of work in TLS1.3 that's not > necessary in TLS1.2). Actually isolating integrity key from encryption key would require two MACs, with inner one inner to encryption and with its own subkey. > The discussion really is about how we're making a number of structural > changes to TLS in the TLS1.3 draft. Some of them have interesting and > possibly unintended consequences (cf the discussion on encrypting the > handshake with respect to encrypting the SNI extension; or the discussion > about doing the hash of the handshake mixin with key derivation interacting > badly with the desire for 1rtt); this particular change had an unintended > consequence that didn't come to light (at least for me) until I got a > specific request and tried to figure out how to satisfy it. What's the problem? It seems that hashing the early handshake is easy enough (and there ARE attacks without this). Is this something about hashing in the "identities" or something like that? -Ilari From nobody Wed Oct 1 11:15:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5BB1A1B43 for ; Wed, 1 Oct 2014 11:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n8hwa1bPtEE for ; Wed, 1 Oct 2014 11:15:33 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2231A1B40 for ; Wed, 1 Oct 2014 11:15:33 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id i17so867152qcy.16 for ; Wed, 01 Oct 2014 11:15:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LUug7t1wGya/+5I3hDYmWihq2Q33sqYGVrCPxLTMPok=; b=WtnaZa4/60qPU0GhzSvc05HAxzqn65K1xh4pVyL9YspJN7u//XFPwHvJbj9AsgL0Pm jM+S7hfb3IDqejuH55vIFuzkLCOzJzuavjnU2yQPHK1cvBR5CAox5GCE3dCZQdG5lDM6 Dsvj2Pr4sSBF/gUbGPGprj4cPUs5Xuita+2zK4z5MVBjw8rrrOhPmmBcFusDUiu1GzWH KQ8Y/2heDMKzGyh0HQoHV/P4BQ3hQwL3IXoh7PwojCDPxr90bpXX5PViyCGyrTXq3IZq b/H7YBq0HOKW/e0KdTQCrjCHHg0Nd5qB8n1NPDR/AcHKbldStYdcN096qnb9/eZ7E3kF xeVQ== X-Gm-Message-State: ALoCoQmWHNSFaRK24SjUg8ESY0hPCfTTUI8ykIlA85eROgSxsrVKSBid0m4S6bXD+Y+55j6aMBse X-Received: by 10.229.219.65 with SMTP id ht1mr47207025qcb.2.1412187332397; Wed, 01 Oct 2014 11:15:32 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:226:5d8b:d39a:536a:43ec? ([2601:a:2a00:226:5d8b:d39a:536a:43ec]) by mx.google.com with ESMTPSA id n88sm1243934qge.12.2014.10.01.11.15.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Oct 2014 11:15:31 -0700 (PDT) Message-ID: <542C44CB.6020707@nthpermutation.com> Date: Wed, 01 Oct 2014 14:15:39 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Dan Harkins References: <542988C5.8050307@nthpermutation.com> <44A2498B-D0CB-415C-A1D8-2E362FD8BDF0@cisco.com> <542B450C.5010304@cs.tcd.ie> <542C2D85.7000705@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7B6B@USMBX1.msg.corp.akamai.com> <542C362A.4010802@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/v5TEPn-ms5ldNme9rO-AmfajPJU Cc: "tls@ietf.org" Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 18:15:35 -0000 On 10/1/2014 1:36 PM, Dan Harkins wrote: > Hi Mike, Hi Dan - The issue I'm describing is not intractable, just inelegant. There's about 100 different ways of solving it, but most require new TLS1.3 cipher suites. SIV is a possibility, McGrew's draft is a better possibility simply because its further along. Any AEAD mode with key diversity is a candidate. Or we can stick with TLS1.2 or IPSEC or build our own. All are more work than just being able to grab an already existing key. Mike > On Wed, October 1, 2014 10:13 am, Michael StJohns wrote: >> On 10/1/2014 12:47 PM, Salz, Rich wrote: >>> I don’t understand why you can’t sell those customers TLS 1.2. >>> >>> Algebraically, I view >>> >>> TLS 1.3 = TLS 1.2 + various_predefined_extensions – >>> some_crypto_mechanisms + epsilon >>> >>> Is there something so important in that epsilon? Or is it just a case >>> of “we must have the latest”? >>> >>> -- >>> >>> Principal Security Engineer, Akamai Technologies >>> >>> IM: rsalz@jabber.me Twitter: RichSalz >>> >> Hi Rich - >> >> TLS1.0 and 1.1 are "obsolete" for some value of obsolete. Once TLS1.3 >> is published, TLS1.2 will also be obsolete. That's as much reality as >> marketing and that causes problems with customers doing check box >> requirements. They say "TLS" and they mean "TLS, the latest and >> greatest" and explaining why you're offering TLS1.2 becomes a painful >> and sometimes business losing proposition. >> >> In your equation above, with respect to this thread only, the actual >> problem is not the " + epsilon" but the "- some_crypto_mechanisms" which >> took away all the mechanisms where the integrity key can be isolated >> from the encryption key. Trying to define new AEAD mechanisms that >> provide this capability *AND* make it in to sufficient commercial stacks >> becomes an interesting problem (and frankly a great deal of work in >> TLS1.3 that's not necessary in TLS1.2). > Such an AEAD mechanism has already been defined. RFC 5297 > specifies AES in SIV mode. SIV takes a single key but it is of the "double > wide" variety where the first half is for the integrity check key and the > second half is the encryption key. So it's possible to isolate one half > from the other assuming that the PRF that generated the double wide > key prevents inferring anything about the first half from knowledge > of the second half (I believe that will be the case for TLS 1.3). > > SIV is a perfectly valid AEAD mechanism and is part of the RFC 5116 > registry. You'd just need to specify it as a TLS1.3 cipher suite. > > It would be very regrettable if SIV became known as the "escrowed > AEAD mode" especially as it has other highly desirable properties, like not > requiring a counter and being robust in the presence of counter misuse, > if one is provided. On the other hand, it's likely that the people requiring > this kind of snooping are some of the very same people that really dislike > SIV mode (and oppose its adoption in standards) so maybe this would be > justice of the poetic kind. > > Be that as it may, I think SIV solves your problem. > > regards, > > Dan. > >> We may end up with TLS1.2, or with another IETF security protocol >> (IPSEC?) or even with something proprietary. >> >> The discussion really is about how we're making a number of structural >> changes to TLS in the TLS1.3 draft. Some of them have interesting and >> possibly unintended consequences (cf the discussion on encrypting the >> handshake with respect to encrypting the SNI extension; or the >> discussion about doing the hash of the handshake mixin with key >> derivation interacting badly with the desire for 1rtt); this particular >> change had an unintended consequence that didn't come to light (at least >> for me) until I got a specific request and tried to figure out how to >> satisfy it. >> >> Later, Mike >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > From nobody Wed Oct 1 11:30:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9F81A1BDD for ; Wed, 1 Oct 2014 11:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5p_7T8I4qn3 for ; Wed, 1 Oct 2014 11:30:42 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id AB1961A1A59 for ; Wed, 1 Oct 2014 11:30:42 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CFAA91657FA; Wed, 1 Oct 2014 18:30:41 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id C49DE165772; Wed, 1 Oct 2014 18:30:41 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub1.dfw01.corp.akamai.com [172.27.25.75]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id C1AE79803E; Wed, 1 Oct 2014 18:30:41 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub1.dfw01.corp.akamai.com ([172.27.25.75]) with mapi; Wed, 1 Oct 2014 13:30:41 -0500 From: "Salz, Rich" To: Michael StJohns , Dan Harkins Date: Wed, 1 Oct 2014 13:30:41 -0500 Thread-Topic: [TLS] AEAD only for TLS1.3 revisit Thread-Index: Ac/do7Hhp2VONYJ+TTS4Guh05o53IwAAeU/w Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7C2C@USMBX1.msg.corp.akamai.com> References: <542988C5.8050307@nthpermutation.com> <44A2498B-D0CB-415C-A1D8-2E362FD8BDF0@cisco.com> <542B450C.5010304@cs.tcd.ie> <542C2D85.7000705@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7B6B@USMBX1.msg.corp.akamai.com> <542C362A.4010802@nthpermutation.com> <542C44CB.6020707@nthpermutation.com> In-Reply-To: <542C44CB.6020707@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sFQCsnaQlW-As4GkSlJv889_UZI Cc: "tls@ietf.org" Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 18:30:43 -0000 Stick with TLS 1.2 The new version doesn't meet the customer needs. Stick = with the old one. Yes, some customers will be upset at not being able to us= e the absolute latest standard. I'm not unsympathetic to that feeling, but = my empathy only goes so far. :)=20 -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Wed Oct 1 16:12:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F53F1A883C; Wed, 1 Oct 2014 16:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUGqTc3twD5z; Wed, 1 Oct 2014 16:12:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6781A882E; Wed, 1 Oct 2014 16:12:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> Date: Wed, 01 Oct 2014 16:12:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Oxfu_jNmeZRGOv2M-66AAI3z2_k Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 23:12:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Prohibiting RC4 Cipher Suites Author : Andrei Popov Filename : draft-ietf-tls-prohibiting-rc4-01.txt Pages : 5 Date : 2014-10-01 Abstract: This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions, and updates [RFC5246], [RFC4346], and [RFC2246]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-prohibiting-rc4-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 1 17:58:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08571A8874 for ; Wed, 1 Oct 2014 17:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkofyHk86eAi for ; Wed, 1 Oct 2014 17:58:06 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3961A8873 for ; Wed, 1 Oct 2014 17:58:06 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 82F747ABA6 for ; Thu, 2 Oct 2014 02:58:04 +0200 (CEST) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 2DDAF43298 for ; Thu, 2 Oct 2014 02:58:04 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2760C1AE9D; Thu, 2 Oct 2014 02:58:04 +0200 (CEST) In-Reply-To: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> To: tls@ietf.org Date: Thu, 2 Oct 2014 02:58:04 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iny3G5Mf0ACFkj9ocWLdtV6SbtY Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 00:58:08 -0000 internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > Title : Prohibiting RC4 Cipher Suites > Author : Andrei Popov > Filename : draft-ietf-tls-prohibiting-rc4-01.txt The list of cipher suites in that document should better include the cipher suite code points! The code points are unique and unambiguous, whereas the artificial symbolic names vary greatly among implementations -Martin PS: I still object to the MUST fail requirement to the server. It is not just plain silly it is also incompatible with rfc2119 section 6. In many situations, the risk in accepting a TLS session with RC4 as a last resort for interop will be quite managable and pretty close to negligible. From nobody Wed Oct 1 18:23:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB581A8883 for ; Wed, 1 Oct 2014 18:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQPDITPTNSrc for ; Wed, 1 Oct 2014 18:23:48 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FCCB1A8887 for ; Wed, 1 Oct 2014 18:23:48 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 19so690621ykq.31 for ; Wed, 01 Oct 2014 18:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RA7eT8x7+v2n0rpTOP1oa3ozlWkKKz+dXCMXB1boSfA=; b=CDE2LEVFT662G+HIkhyLzOBH0Oz6GH9nlnJB/2EAHUchJmlWdN1Cg0tQeD7QmU+uNg ma6Y3Il9PnyYtT9JQwc3wNChIQwaFvjbW3jXVSXvF0J6FI+GM3l/e6OeB3CkN4mplFOJ rLu4sAPBz8puTwbqXl2QhU9bztv7ABW+Fl+viwBkANQZAGy2BhOyB585qLZamB8MAbW8 Uhk8IYDLfVc0mN+cTqTzn+Fc+YFubKBNVt2ol3QaytvmStqxhI/5TasizNGMGW6i3eLQ nEcu1WNul0fD5xWDUxiH+j6EQ8fhAt0hCJJiUJIrzbd565WwPJU+NeEoHtpopcOBOA3a My3Q== MIME-Version: 1.0 X-Received: by 10.236.160.225 with SMTP id u61mr85159862yhk.4.1412213027703; Wed, 01 Oct 2014 18:23:47 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Wed, 1 Oct 2014 18:23:47 -0700 (PDT) In-Reply-To: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> Date: Wed, 1 Oct 2014 18:23:47 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PBkQzapSG87pnEsZ7fTSzQZFkQw Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 01:23:50 -0000 On Wed, Oct 1, 2014 at 5:58 PM, Martin Rex wrote: > internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> Title : Prohibiting RC4 Cipher Suites >> Author : Andrei Popov >> Filename : draft-ietf-tls-prohibiting-rc4-01.txt > > > The list of cipher suites in that document should better include > the cipher suite code points! The code points are unique and unambiguous, > whereas the artificial symbolic names vary greatly among implementations The symbolic names are in the IANA registry alongside the codepoints, and are easier to transcribe correctly. These are not implementation dependent. Sincerely, Watson Ladd > > -Martin > > PS: I still object to the MUST fail requirement to the server. > It is not just plain silly it is also incompatible with > rfc2119 section 6. In many situations, the risk in accepting > a TLS session with RC4 as a last resort for interop will be > quite managable and pretty close to negligible. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Oct 1 18:33:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8331A8882 for ; Wed, 1 Oct 2014 18:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_c7t6mOz-EP for ; Wed, 1 Oct 2014 18:33:03 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id BA7791A887A for ; Wed, 1 Oct 2014 18:33:03 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B0F38165898; Thu, 2 Oct 2014 01:33:02 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id A6429165897; Thu, 2 Oct 2014 01:33:02 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub2.dfw01.corp.akamai.com [172.27.25.76]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id A37AA1E051; Thu, 2 Oct 2014 01:33:02 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub2.dfw01.corp.akamai.com ([172.27.25.76]) with mapi; Wed, 1 Oct 2014 20:33:02 -0500 From: "Salz, Rich" To: "mrex@sap.com" , "tls@ietf.org" Date: Wed, 1 Oct 2014 20:33:01 -0500 Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt Thread-Index: Ac/d2/HkrXpOzG2tQ6aXlZTAM6i8FwABIGdQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7D5B@USMBX1.msg.corp.akamai.com> References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> In-Reply-To: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nLfPtVmQE_n1-RgBT4nAele-LPU Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 01:33:05 -0000 > PS: I still object to the MUST fail requirement to the server. > It is not just plain silly it is also incompatible with > rfc2119 section 6. In many situations, the risk in accepting > a TLS session with RC4 as a last resort for interop will be > quite managable and pretty close to negligible. Agree. -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Thu Oct 2 00:30:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A31E1A0121 for ; Thu, 2 Oct 2014 00:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dV1T_ucR_Bn for ; Thu, 2 Oct 2014 00:30:07 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696E51A00FE for ; Thu, 2 Oct 2014 00:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1412235007; x=1443771007; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=xK60BUKRLdlioUqw+VJsFrvV7UEZ667FjLXy+fB+p1M=; b=NWwK7HHW3219BnTqG6trR5pn0hAewKjDygIV81b3qzBAMUkGddTUL9C+ fRYi3MqjEAGCpYuCep3xoI46zQQpf/wrNavDvGcj9TE/d/m7fTxeOoDJ+ fDfhICfrynUAzzAbbO583s8/FExMR0VY9PfsoTczLbX52y76YMWoardXW M=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="279961462" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 02 Oct 2014 20:30:00 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Thu, 2 Oct 2014 20:30:00 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] AEAD only for TLS1.3 revisit Thread-Index: Ac/eEqu9dVwppUQ6R+iEUqbjuJOv7A== Date: Thu, 2 Oct 2014 07:29:58 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9BF853@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WOsgg9gMC11-unkJb_JSZnN4rLo Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 07:30:16 -0000 "Salz, Rich" writes:=0A= =0A= >Stick with TLS 1.2 The new version doesn't meet the customer needs. Stick= =0A= >with the old one. Yes, some customers will be upset at not being able to u= se=0A= >the absolute latest standard. I'm not unsympathetic to that feeling, but m= y=0A= >empathy only goes so far. :)=0A= =0A= Unfortunately this doesn't work too well in practice, most industry standar= ds=0A= bodies/groups always want to specify the latest version of any crypto proto= col=0A= because, you know, it has a bigger number so it has to be more cromulent.= =0A= While this can prove quite lucrative (and I'm thinking of the number of=0A= industry standards that mandated TLS 1.2 when next to no implementations we= re=0A= actually available), it does mean that you can't escape having to support= =0A= every new protocol fashion statement that comes down the line.=0A= =0A= (Hmm, come to think of it I never tried advertising TLS 1.2 when someone as= ked=0A= for it but always falling back to 1.1, that would give "TLS 1.2" but still= =0A= interoperate with other implementations that hadn't got past 1.1).=0A= =0A= Peter.=0A= From nobody Thu Oct 2 01:01:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB41B1A0151 for ; Thu, 2 Oct 2014 01:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtDNrkbclSel for ; Thu, 2 Oct 2014 01:01:41 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1061A0107 for ; Thu, 2 Oct 2014 01:01:40 -0700 (PDT) In-Reply-To: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Thu, 02 Oct 2014 09:01:29 +0100 To: tls@ietf.org Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Za8v4MqRrOZP4OObq1uRNIolADY Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 08:01:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2 October 2014 01:58:04 BST, mrex@sap.com wrote: >PS: I still object to the MUST fail requirement to the server. Objection from you and Rich noted, but I really do not agree. This draft absolutely must not be watered down. We should treat weak crypters as broadly equivalent to NULL. That is what this does. I think fallback to RC4 is an insecure practice that we must not continue to condone. We have several strong ciphers, some with better performance, and we've known that RC4 was a tad wobbly for years: quite frankly the time for compatibility fallbacks and gentle transitions was 5 years ago or something and is now quite firmly passed. At this point, RC4 is a shambling undead zombie of an old 1980s 8086 crypter. Kill it with fire; stake it in the heart; bury it at a crossroads and dance on its gravestone. And I think that we have reached WG consensus on that point broadly, despite your objections: as there is widespread recognition I think that if we do continue to sanction RC4's use for any reason, that will be the reason we'll never get rid of the damned thing (because people like you and Rich will keep accepting it when presented, to keep your clients with XP and prehistoric Android happy, but that unfortunately also makes Eve happy). Anyone is entirely free to ignore confidentiality if they don't judge it's important in their scenario - but that doesn't mean it's a good idea for the internet at large, or that they weren't warned about the risk and chose to use it anyway. >The list of cipher suites in that document should better include the cipher suite code points! I do agree with this point, it would make it a little clearer and more unambiguous. Subject to perhaps adding the ciphersuite codepoints, +1 for this draft. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJULQZYGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6GIMP/1BKbDfYMpuK99r+Es8AEzKl08kyQ1IHvSnzZlpACyGbGcQAiAHi pNu1bTvaubxCftp0hc5dLgOU1KWB29QK0N6AYW9WOAFV+qIIN5WG29XH/EgK07bz 6FpTO/sXkq1VsPJZH0k0mWzVK6EqmNzFrONL2K43WfYxbli0Noo1fK78Cu82d4+V wMS6WbxxSPjyCWlz2gSjC1H0nA31Bv7AywdhbLJGI+U22yGVCsWyhTX/nG0VG7Qt G9yyXiFMSdrFNVERT7AFxJ4xKoCAkPXotIu8m+dZOD4zzN/lOYDCj3Htmy01lWcD tgj9Xrc06pHYuVpJGxu5s14Sm8qay2S3tv10cZnxRBL+GN+EtN/xnXAVZr7Yu4kS OwAOKLrnMWsjJzlthJGONib0MnYpWMz4FVY1xoqoBpoCkW+Eljb1aOVHJ08Excbd tFPwNXpgL6lG6KiiepfL3yq+Ru+liHMoAiVf8R9KmkwBQIS5H2270DVSkSyopQnB W0ug8aPsMYpY1av2rLMbuCRrrCNirOhdPBukeVEdLBN5fgpJwALTkGXH5xjlIRPV vi9IQdckUHW7rVxHC09XOLLi31p1tSNnZ32TMN2deu2tCe7AoVCQ236T/kPYAwgg w9gnYublcf+wfgBUQ1wGikqQ+KGW2MnNPjPsBHSw7t4Tx1g0r1ONDKgw =QZJ9 -----END PGP SIGNATURE----- From nobody Thu Oct 2 01:26:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6091E1A0173 for ; Thu, 2 Oct 2014 01:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLDeHmU2L-pH for ; Thu, 2 Oct 2014 01:26:04 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF701A0151 for ; Thu, 2 Oct 2014 01:26:03 -0700 (PDT) Received: from localhost ([::ffff:91.64.1.128]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 02 Oct 2014 10:26:02 +0200 id 0000000000000024.00000000542D0C1A.000009F5 Date: Thu, 2 Oct 2014 10:26:02 +0200 From: Hanno =?ISO-8859-1?B?QvZjaw==?= To: tls@ietf.org Message-ID: <20141002102602.3651570f@hboeck.de> In-Reply-To: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-2549-1412238362-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SQmqqmXRAJzTNN9TTSWnVFLHHgA Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 08:26:06 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-2549-1412238362-0001-2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am Wed, 01 Oct 2014 16:12:54 -0700 schrieb internet-drafts@ietf.org: > This document requires that Transport Layer Security (TLS) clients > and servers never negotiate the use of RC4 cipher suites when they > establish connections. This applies to all TLS versions, and > updates [RFC5246], [RFC4346], and [RFC2246]. I really don't want to hold anything here and would welcome if this gets finally out, however there's one thing that bothers me: There is currently no such RFC for RC2 or DES. Both are - considering current RFCs - perfectly valid ciphers according to RFC 2246. It doesn't really make sense to forbid RC4 (likely weak, but no public practical attacks yet) while still allowing RC2(40 bit)/DES (practically broken). Should we change this to "forbid RC2, DES and RC4" ? (there's of course also the potential discussion if further ciphers should be deprecated that are likely weak but not broken - things like DSS - but I'd keep that discussion separate for now) --=20 Hanno B=F6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-2549-1412238362-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJULQwaAAoJEKWIAHK7tR5Cut0P/03QtYCTUeLr7pABcqqObnBb YL+/cK8ZuPTRoO59XtDfM+YhaYtSdnH5LdfDbnaXrugdnaYXc+PRB/sy4vCelnVp Md/xmoaosBezMuEPDkTCOPEZP6Lk4l9KW+b2KzFO87c6+J8BjEpfxdbdmpbO0oih h3VJAMuWj/BrTwOh+0YQEkLKBgWxlQy09KbURFcpE8gOXAKNdDomzm3evW6m1pov bSlEpHjf8YoEAYM5dujRwoatdf8A4GUogbf0Ih44mafqQ1x0RsSSx2wMpaxDFQss BiX6b+1IdkoUnoFpHqoSeIPc3WCtcc/oKUfi1OrY8eQ2svR6oRpbruf0tim8V+om 1Cpf99Ujrf6RIyeSHFy6z3Eao3u73On3VojJ4QREfzgAqJ4vfwbr+fdxE0VmIyIj XBXh5A6dd1BmMl0OFadifpQXPIUzA+sou63XYDpSyHcQQhOfeYNWgi1B/AOEyB0r fNDpUhqnIr8MwriFiqXY8PcLemEBzVvUtzQIPZqXjJT0MhsQVTvimhB4GuqjED9P uKaxGc8Oi+onLnJpDmUMYyc3HP13oa2SUR4XM2armuktTzoQdcwvVVE41pJCl+h8 k3N9Rh1LMuUFQvZo2+omqvQgI0N/Z/Jqctb5jqm5DurD64FF9T9kOYwMRN2/X2ki WmVTB7TUg+c7banmbJMZ =cFCC -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-2549-1412238362-0001-2-- From SRS0=9UCi=6Z=acm.org=bmoeller@srs.kundenserver.de Thu Oct 2 03:44:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09CC1A02E2 for ; Thu, 2 Oct 2014 03:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os_G8XJDHTM8 for ; Thu, 2 Oct 2014 03:44:11 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DDC1A02DD for ; Thu, 2 Oct 2014 03:44:10 -0700 (PDT) Received: from mail-yh0-f53.google.com (mail-yh0-f53.google.com [209.85.213.53]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0M4qlR-1YRTXG2ss1-00yvFe; Thu, 02 Oct 2014 12:44:08 +0200 Received: by mail-yh0-f53.google.com with SMTP id b6so590373yha.12 for ; Thu, 02 Oct 2014 03:44:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.54.101 with SMTP id h65mr35532091yhc.47.1412246646668; Thu, 02 Oct 2014 03:44:06 -0700 (PDT) Received: by 10.170.194.15 with HTTP; Thu, 2 Oct 2014 03:44:06 -0700 (PDT) In-Reply-To: References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> Date: Thu, 2 Oct 2014 12:44:06 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=bcaec508f598b5c5a905046e4b34 X-Provags-ID: V02:K0:DdA+LBRcd74sSgXFQu0EtVJs9r/wrZ+8nQh1Pm5EhP+ JEWFhZhWWTKBEzmf5mGyP8TWRL6wNfpmJsZDLV4Ei4qnyqirMJ swp/EIvXQ4CQXUNR7oX1wHQulbEjPtbxQgN9eD9+yIpSshbuCc LvW7TH4OmD9e8cWgWyMtNX8dqYU/I7BSnlgtOpQSOTBmfGpTBK lmYoGpUAE5vJr31fhjdoPtX4nLjLfr9Z1hYrfoJa/jAsiQ8T8q 5P3O0yurhzG2/6i9FRft6nII5N1PPTGJiX+SkqEYKjlnqXjq98 Q5wb+T0V5mwYdGavfrCObqmEmyMAPTQZKQT0I9+j3+ZwENkuRF AUagYPQx6gWEUL6QjVsHAUGOyr005eCWoRiPTC8eA0fE0c2H6B GzzDC5NvVlF6FFNtAPO8eGgBQT0EnT6F9qiY/NcpGtVj9E1XdC NMF7V X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/09_t1pshmr3aOnimLM94rhhguDk Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 10:56:31 -0000 --bcaec508f598b5c5a905046e4b34 Content-Type: text/plain; charset=UTF-8 Alyssa Rowan : This draft absolutely must not be watered down. We should treat weak > crypters as broadly equivalent to NULL. That is what this does. > NULL is not currently a MUST NOT ... of course, having a cipher suite that intently and expressly does not encrypt is clearer than having a cipher suite that offers weak encryption, so it could make sense to have a MUST NOT for RC4 even as NULL remains around for use cases that need it. Anyone is entirely free to ignore confidentiality if they don't judge it's > important in their scenario - but that doesn't mean it's a good idea for > the internet at large, or that they weren't warned about the risk and chose > to use it anyway. > Translated from prose, I think you're saying SHOULD NOT. Bodo --bcaec508f598b5c5a905046e4b34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alys= sa Rowan <akr@akr.io>:

This draft absolutely must not be watered down. We s= hould treat weak crypters as broadly equivalent to NULL. That is what this = does.

NULL is not currently a MUST NOT = ... of course, having a cipher suite that intently and expressly does not e= ncrypt is clearer than having a cipher suite that offers weak encryption, s= o it could make sense to have a MUST NOT for RC4 even as NULL remains aroun= d for use cases that need it.

Anyone is entirely free to ignore confidentiality if they don't judge i= t's important in their scenario - but that doesn't mean it's a = good idea for the internet at large, or that they weren't warned about = the risk and chose to use it anyway.

Tr= anslated from prose, I think you're saying SHOULD NOT.

Bodo

--bcaec508f598b5c5a905046e4b34-- From SRS0=9UCi=6Z=acm.org=bmoeller@srs.kundenserver.de Thu Oct 2 03:56:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5EF1A02F4 for ; Thu, 2 Oct 2014 03:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.586 X-Spam-Level: X-Spam-Status: No, score=0.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_BACK=2.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WGDqTtkiU0U for ; Thu, 2 Oct 2014 03:56:19 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220EF1A01F9 for ; Thu, 2 Oct 2014 03:56:19 -0700 (PDT) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by mrelayeu.kundenserver.de (node=mreue001) with ESMTP (Nemesis) id 0M5CrX-1YS1Yl2QQx-00za3G; Thu, 02 Oct 2014 12:56:16 +0200 Received: by mail-yk0-f174.google.com with SMTP id 142so834316ykq.19 for ; Thu, 02 Oct 2014 03:56:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.2.164 with SMTP id 24mr3797432yhf.126.1412247374527; Thu, 02 Oct 2014 03:56:14 -0700 (PDT) Received: by 10.170.194.15 with HTTP; Thu, 2 Oct 2014 03:56:14 -0700 (PDT) In-Reply-To: <20141002102602.3651570f@hboeck.de> References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> <20141002102602.3651570f@hboeck.de> Date: Thu, 2 Oct 2014 12:56:14 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e011823aa18042605046e77a0 X-Provags-ID: V02:K0:M68/gowJ/TUhc2m8YiWs02sWQc1fH6G3Zy6VfoVUm/C DVjK0BD/XCilZpOcDSQtP7OhCpOIE67+JphH0Qh3JoiNUwB9lU UqbGD8evKGUJhBiqA9R9tnQz3rWfddNrXHfzOzNa9S1YhdPcOZ 6aTL3tNkHWB0j5vK9qGUGgo18j4+0/3CAw/m4IP6QaSpp7uZQX 16/9fNNKUL/l1WHqalrU/Xdx31nsf/PE6gJIl6BGAIT9On58CN BEj7Gk+U62b2WCWgn7TVdBROEyG4wFuo4Rzs+FSsOrAxxJEFD/ NuME+8osdT9txQAy3R7tjDERrWQSMBLrx0Mf6yZUbTnsjV2lD+ ZQXnWY3vzgoNBxzofXxUkm6UJ89r7tYzeTVGXidgl5Ef6TurXe PseU5tpf/cq4Z8+eASQsrs3aluyMsERipXn1A+7JtiW8zh8AsN JksDQ X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MlsxVcxTM2PR0T3sS4Ik_4Loz5w Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 11:00:22 -0000 --089e011823aa18042605046e77a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hanno B=C3=B6ck : > There is currently no such RFC for RC2 or DES. Both are - considering > current RFCs - perfectly valid ciphers according to RFC 2246. > Should we change this to "forbid RC2, DES and RC4" ? The reasons that this spec talks only about RC4 presumably are that (1) only RC4 made it into the TLS 1.2 spec, and (2) RC4 currently has much more widespread implementation support (and practical deployment). The I-D, however, says "This applies to all TLS versions, and updates [RFC5246], [RFC4346], and [RFC2246]", so (1) is not a good reason (it would seem cleaner to say something about the other ciphers too, for the older protocol versions); and (2) isn't a good reason either (the spec should stand for itself, not just provide the delta on top of current folklore knowledge that certain ciphers are out). So I think a more comprehensive cipher suites MUST NOT / SHOULD NOT document would be appropriate. (40-bit encryption already is an explicit MUST NOT for TLS 1.1, but is there any spec that clearly speaks against using it with TLS 1.0?) Bodo --089e011823aa18042605046e77a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hann= o B=C3=B6ck <hanno@hboeck.de>:
=C2=A0
There is currently no such RFC for RC2 or DES. Both are - considering
current RFCs - perfectly valid ciphers according to RFC 2246.

Should we change this to "forbid RC2, DES and RC4" ?
=

The reasons that this spec talks only about RC4 presuma= bly are that

(1) =C2=A0only RC4 made it into the T= LS 1.2 spec, and
(2) =C2=A0RC4 currently has much more widespread= implementation support (and practical deployment).

The I-D, however, says "This applies to all TLS versions, and update= s [RFC5246], [RFC4346], and [RFC2246]", so (1) is not a good reason (i= t would seem cleaner to say something about the other ciphers too, for the = older protocol versions); and (2) isn't a good reason either (the spec = should stand for itself, not just provide the delta on top of current folkl= ore knowledge that certain ciphers are out).

So I = think a more comprehensive cipher suites MUST NOT / SHOULD NOT document wou= ld be appropriate. (40-bit encryption already is an explicit MUST NOT for T= LS 1.1, but is there any spec that clearly speaks against using it with TLS= 1.0?)

Bodo

--089e011823aa18042605046e77a0-- From nobody Thu Oct 2 04:01:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9051A0306 for ; Thu, 2 Oct 2014 04:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg1oeA1kG-B7 for ; Thu, 2 Oct 2014 04:01:54 -0700 (PDT) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613151A02F8 for ; Thu, 2 Oct 2014 04:01:54 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s92B1r8q008978 for ; Thu, 2 Oct 2014 07:01:53 -0400 Date: Thu, 2 Oct 2014 07:01:53 -0400 (EDT) From: Hubert Kario To: tls Message-ID: <4742277.4920215.1412247713747.JavaMail.zimbra@redhat.com> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9BF853@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C739B9BF853@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.6] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922) Thread-Topic: [TLS] AEAD only for TLS1.3 revisit Thread-Index: Ac/eEqu9dVwppUQ6R+iEUqbjuJOv7Fa/X1T4 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4lyyego-US5BBbdSqIPvO8LspEU Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 11:01:56 -0000 ----- Original Message ----- > From: "Peter Gutmann" > To: "" > Sent: Thursday, 2 October, 2014 9:29:58 AM > Subject: Re: [TLS] AEAD only for TLS1.3 revisit > > "Salz, Rich" writes: > > >Stick with TLS 1.2 The new version doesn't meet the customer needs. Stick > >with the old one. Yes, some customers will be upset at not being able to use > >the absolute latest standard. I'm not unsympathetic to that feeling, but my > >empathy only goes so far. :) > > (Hmm, come to think of it I never tried advertising TLS 1.2 when someone > asked > for it but always falling back to 1.1, that would give "TLS 1.2" but still > interoperate with other implementations that hadn't got past 1.1). or advertising TLS1.3 but also no TLS1.3 compatible ciphers (since they are incompatible with the use case in question) -- Regards, Hubert Kario From nobody Thu Oct 2 04:41:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84E91A1A66 for ; Thu, 2 Oct 2014 04:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4apOiemlJu5 for ; Thu, 2 Oct 2014 04:41:05 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385BC1A1A4E for ; Thu, 2 Oct 2014 04:41:05 -0700 (PDT) In-Reply-To: References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Thu, 02 Oct 2014 12:40:57 +0100 To: "tls@ietf.org" Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gRypqY9M9r32x-suN88c9kksFL4 Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 11:41:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2 October 2014 11:44:06 BST, Bodo Moeller wrote: >NULL is not currently a MUST NOT ... of course, having a cipher suite that intently and expressly does not encrypt is clearer than having a cipher suite that offers weak encryption, so it could make sense to have a MUST NOT for RC4 even as NULL remains around for use cases that need it. Good point. I think that's clearer, although I also think use cases that need NULL are either poorly addressed by TLS or looking at it the wrong way as they own endpoints and can monitor traffic safely there, so keeping NULL around is IMHO more trouble than it's worth in TLS 1.3. >Translated from prose, I think you're saying SHOULD NOT. Except that I honestly do not think any "valid" reason exists to use RC4 at this point - which equates to MUST NOT. Let's go through possible justifications for why I think that, and alternatives: • Backwards compatibility with rusty legacy implementations? Fine, begrudgingly, choose 3DES, if you *really* must, but you probably SHOULD NOT (implementations that legacy are either out of support so you have bigger problems or can be security patched to use strong ciphersuites instead). It's too weak? (What, and you think RC4's better?) It's affected by BEAST? (Countermeasures against active attacks, disable scripting and Java, and 1,(n-1) splitting.) Bad performance? (There's plenty of 3DES hardware.) • High performance? AES-GCM (in the presence of hardware support) or ChaCha20-Poly1305. Both faster than RC4 unless you're packing an 8-bit, and quite reasonable even if you are. • A special deployment where both sides don't care about confidentiality? NULL, then (and repent at leisure when an attacker breaches your trusted network and you've egg all over your face). Nope, I'm drawing a blank here. Like the 40-bit ciphers, it just doesn't make any sense to me. I can think of no valid reason to use RC4 where something else doesn't work better. Of course I can't force others into that viewpoint, but I can and will say anyone still using it after this RFC is published were warned about the dangers, and of better alternatives, and chose to ignore them to everyone's detriment. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJULTnIGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6ju8P/1fVlVOHR4GlaFKo1iLj14XzN0d3CzmfkJ97Mxp2qbqt9O0PxEth gV8OADR1L/YOb5ihzDRczV04R5n3F0Var2mW1SX1bqFIHY6pODAJtqWKL3DzBjR+ B1FQPSCzX/eAxArDusoztdklxfNAWxoHSDWodQXtb2J+Zwuu2vUg9ucFP/oJiB9U BYQw9VfpnsdkJNUXeEIEkMmWL1RpJlTUgepZIuD3YWRjDBHDpxJokyZYEu7wJHV/ d9mC9yEaJmncU5fMqHHupqitIfGzR3aPqDkjYaL/DrRXg+NXIue8EjqgV3wuqDAx eL/lHzSxFNoCryF3upsfER1G+UHD9Alf6YOk2YXSes3yMaXCeGzpMrOq6qnigHAV pc7zhRGkGUF1YCbdhN6PGNYzi/iLeSNtCowTSLbOdhENTvMNRxsObDTDeC7IAdgL afo+BRwTPbh/4qHhA2hm1uQ4A6W+0LIQfYSKPKTS+EZ5Gmh4PmTstl27SJsjRPPr AQs3aP3mMQg797Lc31zbTX3amtWOn5RAf3qCjmbBR6naJRLbP6tWb90d9Py+lS6V k0z0yTJRQQIBteBr2PkYYXmHl9sVpfSx5kI8ub2+UQBykl/iNZeVq41rOA0i4fLx gWv6KjUURN/aLlEFRYKs3ygt1jyTwrGZ4NydssLtJfc4e8YyhrvI+mi1 =lZx0 -----END PGP SIGNATURE----- From nobody Thu Oct 2 05:33:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A201A6FC0 for ; Thu, 2 Oct 2014 05:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U3H5ASmohuI for ; Thu, 2 Oct 2014 05:33:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75411A6FA8 for ; Thu, 2 Oct 2014 05:33:56 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s92CXuBo030479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 2 Oct 2014 08:33:56 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s92CXsbg029254 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 2 Oct 2014 08:33:55 -0400 Message-ID: <1412253233.27112.31.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "tls@ietf.org" Date: Thu, 02 Oct 2014 14:33:53 +0200 In-Reply-To: References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/itE3XWowPQ-gq_-2XKpRSQ-yUOU Subject: [TLS] adopting ChaCha20 as a WG item was: I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 12:33:58 -0000 On Thu, 2014-10-02 at 12:40 +0100, Alyssa Rowan wrote: > Let's go through possible justifications for why I think that, and > alternatives: > [...] > • High performance? AES-GCM (in the presence of hardware support) or > ChaCha20-Poly1305. Both faster than RC4 unless you're packing an 8-bit, > and quite reasonable even if you are. And that reminds me that Chacha20 does not exist yet. Would it be reasonable for the WG to adopt the current draft [0] given that Yoav's draft has been adopted by CFRG? regards, Nikos [0]. http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02 [1]. https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-01 From nobody Thu Oct 2 05:58:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B231A6FA8 for ; Thu, 2 Oct 2014 05:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyQlsGmdXRWB for ; Thu, 2 Oct 2014 05:58:09 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27FEC1A6FE6 for ; Thu, 2 Oct 2014 05:58:08 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gi9so2331227lab.35 for ; Thu, 02 Oct 2014 05:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YFtWnUUxnlKTRy36bcJefG8gjN0RtndIUpScntLZSUw=; b=r65G0lCae3nhxkqN7Ela9wh+zKYoGczgWfql6arqCDIquuhKyh7z5IQqo8YopUZP+H ZITpfHmmHEBby3O82dvcprtSSSjSjuea7SbBXipvidn0zCMPFx2/GrhS6rDGiWxrGlWP kW97iyasxsMZC9UpwukzEgdPajG9XKz/6wjWv8mTyQHBbrjSmnPvf7JG/8ey5QcyHgGa gRCakDttM7IbshUIVNM0bGdJFMS9ZSVva8tUjG7+zte+KF/SS0vBLSc2Y0Uc6LtAkfDc ZOTqLf3232TYhQe9FzcATkSI7VJxRyNVWv6unOwJNvwDSKh/ek5SR4//IXUL//iBwBS3 zXxQ== X-Received: by 10.152.202.135 with SMTP id ki7mr57794898lac.16.1412254687296; Thu, 02 Oct 2014 05:58:07 -0700 (PDT) Received: from [172.24.251.145] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id x1sm1574885lag.16.2014.10.02.05.58.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 05:58:06 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <1412253233.27112.31.camel@dhcp-2-127.brq.redhat.com> Date: Thu, 2 Oct 2014 15:58:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <73B75C67-2608-4210-A624-14934E08016E@gmail.com> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <1412253233.27112.31.camel@dhcp-2-127.brq.redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/I802VykuBUGxeN6fO0Rdq4ZClh8 Cc: "tls@ietf.org" Subject: Re: [TLS] adopting ChaCha20 as a WG item was: I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 12:58:11 -0000 Hi, Nikos I think yes, especially considering that CFRG has just started RGLC on = the document. I think it=92s debatable whether we need so many ciphersuites. = Considering that TLS 1.3 will be PFS-only and AEAD-only, I=92m not sure = we need the ciphersuites in section 4.1, and the RSA (without DHE) = ciphersuites. The feedback I got in IPsecME was that we didn=92t need = anything but the AEAD. But that kind of thing can be debated in the = working group. Yoav On Oct 2, 2014, at 3:33 PM, Nikos Mavrogiannopoulos = wrote: > On Thu, 2014-10-02 at 12:40 +0100, Alyssa Rowan wrote: >=20 >> Let's go through possible justifications for why I think that, and >> alternatives: >> [...] >> =95 High performance? AES-GCM (in the presence of hardware support) = or >> ChaCha20-Poly1305. Both faster than RC4 unless you're packing an = 8-bit, >> and quite reasonable even if you are. >=20 > And that reminds me that Chacha20 does not exist yet. Would it be > reasonable for the WG to adopt the current draft [0] given that Yoav's > draft has been adopted by CFRG? >=20 > regards, > Nikos >=20 > [0]. http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02 > [1]. https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-01 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Oct 2 06:20:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C901D1A7D82 for ; Thu, 2 Oct 2014 06:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wox-ZAvJJbsm for ; Thu, 2 Oct 2014 06:19:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3D81A033B for ; Thu, 2 Oct 2014 06:19:57 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s92DJttD021815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 2 Oct 2014 09:19:55 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s92DJrD1024827 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2014 09:19:54 -0400 Message-ID: <1412255992.27112.41.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Yoav Nir Date: Thu, 02 Oct 2014 15:19:52 +0200 In-Reply-To: <73B75C67-2608-4210-A624-14934E08016E@gmail.com> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <1412253233.27112.31.camel@dhcp-2-127.brq.redhat.com> <73B75C67-2608-4210-A624-14934E08016E@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8OsbmaJR2CiYfz1TBrO_7-vQVjE Cc: "tls@ietf.org" Subject: Re: [TLS] adopting ChaCha20 as a WG item was: I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 13:20:00 -0000 On Thu, 2014-10-02 at 15:58 +0300, Yoav Nir wrote: > Hi, Nikos > > I think yes, especially considering that CFRG has just started RGLC on > the document. > > I think it’s debatable whether we need so many ciphersuites. > Considering that TLS 1.3 will be PFS-only and AEAD-only, I’m not sure > we need the ciphersuites in section 4.1, and the RSA (without DHE) > ciphersuites. The feedback I got in IPsecME was that we didn’t need > anything but the AEAD. But that kind of thing can be debated in the > working group. Hello Yaov, I agree. The non-AEAD ciphersuites are in order to be implementable to pre-TLS 1.2. Whether they are applicable to TLS 1.3 or not, is outside the scope of this document. regards, Nikos From nobody Thu Oct 2 07:13:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3EA1A03A6 for ; Thu, 2 Oct 2014 07:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_X6iqU82nGZ for ; Thu, 2 Oct 2014 07:13:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 8896B1A037D for ; Thu, 2 Oct 2014 07:13:03 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D4CE447598; Thu, 2 Oct 2014 14:13:02 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C40CC47597; Thu, 2 Oct 2014 14:13:02 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub1.dfw01.corp.akamai.com [172.27.25.75]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id A309C202C; Thu, 2 Oct 2014 14:13:02 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub1.dfw01.corp.akamai.com ([172.27.25.75]) with mapi; Thu, 2 Oct 2014 09:13:00 -0500 From: "Salz, Rich" To: Peter Gutmann , "" Date: Thu, 2 Oct 2014 09:12:57 -0500 Thread-Topic: [TLS] AEAD only for TLS1.3 revisit Thread-Index: Ac/eEqu9dVwppUQ6R+iEUqbjuJOv7AAODcEg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E77@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C739B9BF853@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9BF853@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ohRnng6MhTyR5CX2UBDk9LDes-c Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 14:13:13 -0000 > (Hmm, come to think of it I never tried advertising TLS 1.2 when someone > asked for it but always falling back to 1.1, that would give "TLS 1.2" bu= t still > interoperate with other implementations that hadn't got past 1.1). I'm shocked to hear that you never did that. -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Thu Oct 2 07:22:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353DF1A03D0 for ; Thu, 2 Oct 2014 07:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0YkWN_gCRzJ for ; Thu, 2 Oct 2014 07:22:13 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id E869B1A03AB for ; Thu, 2 Oct 2014 07:22:12 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8BB434758B for ; Thu, 2 Oct 2014 14:22:12 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 7F52147586 for ; Thu, 2 Oct 2014 14:22:12 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub1.dfw01.corp.akamai.com [172.27.25.75]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 5EC7280044 for ; Thu, 2 Oct 2014 14:22:12 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub1.dfw01.corp.akamai.com ([172.27.25.75]) with mapi; Thu, 2 Oct 2014 09:22:12 -0500 From: "Salz, Rich" To: "tls@ietf.org" Date: Thu, 2 Oct 2014 09:22:09 -0500 Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt Thread-Index: Ac/eFx5G9KX6V1LFT0iX5DmY7N3z0QANGEkQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/spzQMhw9NUVlVAnub_KAonAEzY4 Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 14:22:14 -0000 After thinking about this a bit more, I changed my mind. I've argued that TLS 1.3 doesn't have to cover every use case supported by = TLS 1.2. On the crypto front, if we (my employer) has to allow RC4 Android= 2.2 or old embedded devices (like WWW-TV's), that doesn't change the fact = that what these devices are doing isn't good. I'd prefer to see something = like servers should only accept RC4 if it is the best cipher the client sup= ports, but so be it. -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Thu Oct 2 07:45:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3381A044F for ; Thu, 2 Oct 2014 07:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNW5AZXlB-K7 for ; Thu, 2 Oct 2014 07:44:55 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F111A046F for ; Thu, 2 Oct 2014 07:44:41 -0700 (PDT) Received: from mail-yh0-f50.google.com (mail-yh0-f50.google.com [209.85.213.50]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0Lba15-1XyI4j2vmt-00lI4X; Thu, 02 Oct 2014 16:44:39 +0200 Received: by mail-yh0-f50.google.com with SMTP id a41so275210yho.23 for ; Thu, 02 Oct 2014 07:44:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.140.97 with SMTP id d61mr3554120yhj.164.1412261077610; Thu, 02 Oct 2014 07:44:37 -0700 (PDT) Received: by 10.170.194.15 with HTTP; Thu, 2 Oct 2014 07:44:37 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> Date: Thu, 2 Oct 2014 16:44:37 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=20cf303ea810dc788f050471a7fd X-Provags-ID: V02:K0:AkBBEsk3DJYbeBb0N88nJtZzJhsyjDxiSFXdUlYTPf3 ZYvmfvHLFgluBJoFgrW4BMO1ZRWCUo48XcacpU3xUg6GY6X6DF ytYPcmhyQF44C+xttBfr+fHyqymcOu/ZEy7Vxx6EB4zJ/LM9Tx uiRAcdK5FQkoa3K0Pytu3U634kLyAvb/gf7k9w0yKOwWhtkss3 HzJDNTLd5i5LxKK0WolV0xDY30try9VEMyQX+qw8wxxy/LBsWM +iPoFt4eYUGGJjCscQsz8wiFnSRLkVdX3VfjrW5sK2AhloMabR KdNs5RnmySRBDQABtfxD6XWNgJ/UZNqmhJXO+zpKziQURskaad sRmo5bPH93cd4XQ9GUzO6+7g4oWzrb6AFM9JdaSJIajSDcKic0 hozlDQhqLKzVSU+QL4YhOrXaBAzbgtfy8NM8OZ7Nv5PD3DbsVL t37oA X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7qf7xBFO1qXt7sJYfyEihyI1hOE Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 14:44:57 -0000 --20cf303ea810dc788f050471a7fd Content-Type: text/plain; charset=UTF-8 One technical issue here is that we keep updating specs that are also (supposedly) "obsolete". I.e., "If you do that thing that you're not supposed to do, here's how". It seems to me that having a bit of a gray area then is unavoidable ... and often you *do* need some latitude in backwards-compatible cases, assuming you support these to achieve backwards-compatibility. (www.microsoft.com, for example, does allow RC4 cipher suites when using TLS 1.0, which would be incompatible with that MUST NOT, since it expressly applies to TLS 1.0 too.) If the spec isn't aligned with reality, that's a bit of a problem. You shouldn't have to interpret a MUST NOT as a SHOULD NOT. Maybe the spec should have strict MUST NOT requirements for TLS 1.2, but make mere recommendations for the legacy protocols? (As mentioned before, it would be good to also document that various other ciphers like RC2 also aren't a good idea to use, even which TLS 1.1 which has them in the spec.) Bodo --20cf303ea810dc788f050471a7fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One technical issue here is that we keep updating specs th= at are also (supposedly) "obsolete". I.e., "If you do that t= hing that you're not supposed to do, here's how". It seems to = me that having a bit of a gray area then is unavoidable ... and often you *= do* need some latitude in backwards-compatible cases, assuming you support = these to achieve backwards-compatibility.

(www.microsoft.com, for example, does allow RC4 = cipher suites when using TLS 1.0, which would be incompatible with that MUS= T NOT, since it expressly applies to TLS 1.0 too.)

If the spec isn't aligned with reality, that's a bit of a problem.= You shouldn't have to interpret a MUST NOT as a SHOULD NOT.
=
Maybe the spec should have strict MUST NOT requirements for = TLS 1.2, but make mere recommendations for the legacy protocols? (As mentio= ned before, it would be good to also document that various other ciphers li= ke RC2 also aren't a good idea to use, even which TLS 1.1 which has the= m in the spec.)

Bodo

--20cf303ea810dc788f050471a7fd-- From nobody Thu Oct 2 10:02:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14431A893B for ; Thu, 2 Oct 2014 10:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyyfgSt20z26 for ; Thu, 2 Oct 2014 10:02:12 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496DB1A893F for ; Thu, 2 Oct 2014 10:02:07 -0700 (PDT) Message-ID: <542D850E.2060900@akr.io> Date: Thu, 02 Oct 2014 18:02:06 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: "tls@ietf.org" References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CCJ-Tq0-5r7NebLI935wKsnijUg Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:02:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2 October 2014 15:44:37 BST, Bodo Moeller wrote: > It seems to me that having a bit of a gray area then is > unavoidable ... and often you *do* need some latitude in > backwards-compatible cases, assuming you support these to achieve > backwards-compatibility. As I've pointed out, if you're forced into backwards compatibility with rusty legacy, 3DES is, though crappy, a less crappy choice than RC4. As Rich points out, just because legacy devices are indeed out there doesn't mean that they do TLS safely, and doesn't mean we shouldn't prohibit unsafe practice like using weak ciphers. > (www.microsoft.com, for example, does allow RC4 cipher suites when > using TLS 1.0, which would be incompatible with that MUST NOT, > since it expressly applies to TLS 1.0 too.) This draft is a warning to implementers and deployers of TLS that they MUST change their allowed ciphersuites to completely exclude RC4, because RC4 isn't safe enough to use in TLS (or really for any purpose anymore). Pointing to examples of RC4 still being allowed in the wild only further demonstrates the need for this draft as-is. > If the spec isn't aligned with reality, that's a bit of a problem. > You shouldn't have to interpret a MUST NOT as a SHOULD NOT. Reality is, unfortunately, that RC4 should have obsoleted years ago. That is indeed a bit of a problem - one we now need to fix rapidly. > Maybe the spec should have strict MUST NOT requirements for TLS > 1.2, but make mere recommendations for the legacy protocols? No, not sure I follow your reasoning here: RC4 is no less weak when used with SSLv3 or TLS 1.0 than with TLS 1.2. Might even be weaker, if there's a way to trick a server into selecting it (hence the fallback SCSV draft). I see no reason the prohibition ought not be absolute. Regarding obsolete ciphers such as RC2 and DES, I don't think the need to prohibit them is quite as urgent, because people aren't actually using them in the wild. (Well, not _many_ people, anyway.) I would indeed support their deprecation - but perhaps in a separate document, as I'm concerned that any unnecessary delay with this one is another day that RC4's still actively being used by many, even when better alternatives are available - which is another day of traffic Eve can record - and, I fear, break, now or any time later at their leisure. The sooner we can proceed, the sooner we can start working to fix that. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJULYUNAAoJEOyEjtkWi2t6cZYQAK/LJRHi9BjIDkyQgTGiSRrl D7tawBqIyR/0IErV+bz1UrIvCifx4Lrn99qscMEfuklRjEmJ0QJa2qAYYB51LPOi +zxphHrXwSA3iofgTqawPLq3A+N6mHM38TBKhhxRW8oF8Y7zcNtvIAFRAWZ3f5zM vAN9GW4MJLbDYpbu4mxsJ1qLhZ8+Ojo3IIcJnhhhZYJ6pdlwoQzWlUOzd9itdbbo Nn1DnZUvJBIHS8uGclFamZDlg+f4b4Djy6msQH1C2VdQkgaZxAHr/E+gaU/whpTY Qfc9FooyaEH5tpAiKDfcTjyhhgWatsJQhx39I+Mt/t9Ht+H7FR3kxHB4XRCgiSyg ASvobV/ATo3aSflqeUrO7myS7cJWXH2gHCVKCXIw0JxIT40j5q08VtUsd9b1Db9Z HaXWibvBYcngkGvpHC5CW+P7vNDP0x4wUPNaa/w8KBO7dZcqwFKC7BHpcekIKt4A yQjiPAG2tXDmqd5Y9GykcJU0kFZucPbulcGnNW1KeAoZhgBmUzsDVq0gw6U+VQ/J 1vFcwG2DlCl1ICBxHEjCcNAiJ3K0MX5Dz6wMD2NaQ1CvlqU3g7HWHJha0VbMsQns P1SLllT8Kjmm/KpJyqiYE0hbuYfWnUPv5BeKW5eVuBzZA2D8maHSBilIZIvPbv8K a1qiinNciHhRIs14X8kV =GfyS -----END PGP SIGNATURE----- From nobody Thu Oct 2 10:54:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12AD1A86ED for ; Thu, 2 Oct 2014 10:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cpcshfZz5f9 for ; Thu, 2 Oct 2014 10:54:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4B41A03A9 for ; Thu, 2 Oct 2014 10:54:09 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB417.namprd03.prod.outlook.com (10.141.92.12) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 2 Oct 2014 17:54:07 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1039.011; Thu, 2 Oct 2014 17:54:07 +0000 From: Andrei Popov To: "tls@ietf.org" Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt Thread-Index: AQHP3c1Ub4FUPtdXakGIHJMHMTXmG5wb/DwAgAB2TYCAAGpcgIAABkeAgAAmaQCAAAbnYA== Date: Thu, 2 Oct 2014 17:54:07 +0000 Message-ID: <64cfd9c21a3f430287b7a0d30908b007@BL2PR03MB419.namprd03.prod.outlook.com> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> In-Reply-To: <542D850E.2060900@akr.io> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB417; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(3905003)(189002)(69224002)(199003)(377454003)(106356001)(64706001)(107046002)(2351001)(107886001)(4396001)(105586002)(74316001)(99396003)(76482002)(20776003)(10300001)(120916001)(80022003)(46102003)(106116001)(95666004)(21056001)(99286002)(85852003)(86612001)(87936001)(33646002)(230783001)(76576001)(2501002)(15975445006)(31966008)(93886004)(85306004)(19580405001)(19580395003)(108616004)(50986999)(97736003)(86362001)(575784001)(2656002)(101416001)(76176999)(54356999)(110136001)(92566001)(24736002)(3826002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kONgTbdUv-FSdEjOLz2S-mzxjP4 Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:54:13 -0000 Thanks for all the comments; I've noticed 3 recurring themes of discussion = on this thread so far: 1. Add IANA code points for RC4 cipher suites listed in the Appendix. I have no objection to this; will do since a lot of people seem to find it = helpful. 2. "TLS servers MUST NOT select an RC4 cipher suite" is too strict/constrai= ning/hard to deploy/etc.=20 If we removed this MUST NOT, this would not be a prohibiting-rc4 draft, but= a best practice recommendation. We have TLS-BCP for recommendations. The i= dea of prohibiting-rc4 is to completely remove a weak cipher suite. 3. But there are other weak cipher suites: EXPORT, DES, RC2, MD5...=20 Totally agree; these need to be removed as well. However, we've been discus= sing prohibiting-rc4 for over a year now. I think we should let this draft = proceed so that we can make some progress. I don't mind authoring a new I-D= (or I-Ds) prohibiting EXPORT, DES, RC2, MD5 ciphers. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Alyssa Rowan Sent: Thursday, October 2, 2014 10:02 AM To: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2 October 2014 15:44:37 BST, Bodo Moeller wrote: > It seems to me that having a bit of a gray area then is unavoidable=20 > ... and often you *do* need some latitude in backwards-compatible=20 > cases, assuming you support these to achieve backwards-compatibility. As I've pointed out, if you're forced into backwards compatibility with rus= ty legacy, 3DES is, though crappy, a less crappy choice than RC4. As Rich points out, just because legacy devices are indeed out there doesn'= t mean that they do TLS safely, and doesn't mean we shouldn't prohibit unsa= fe practice like using weak ciphers. > (www.microsoft.com, for example, does allow RC4 cipher suites when=20 > using TLS 1.0, which would be incompatible with that MUST NOT, since=20 > it expressly applies to TLS 1.0 too.) This draft is a warning to implementers and deployers of TLS that they MUST= change their allowed ciphersuites to completely exclude RC4, because RC4 i= sn't safe enough to use in TLS (or really for any purpose anymore). Pointing to examples of RC4 still being allowed in the wild only further de= monstrates the need for this draft as-is. > If the spec isn't aligned with reality, that's a bit of a problem.=20 > You shouldn't have to interpret a MUST NOT as a SHOULD NOT. Reality is, unfortunately, that RC4 should have obsoleted years ago. That is indeed a bit of a problem - one we now need to fix rapidly. > Maybe the spec should have strict MUST NOT requirements for TLS 1.2,=20 > but make mere recommendations for the legacy protocols? No, not sure I follow your reasoning here: RC4 is no less weak when used wi= th SSLv3 or TLS 1.0 than with TLS 1.2. Might even be weaker, if there's a w= ay to trick a server into selecting it (hence the fallback SCSV draft). I s= ee no reason the prohibition ought not be absolute. Regarding obsolete ciphers such as RC2 and DES, I don't think the need to p= rohibit them is quite as urgent, because people aren't actually using them = in the wild. (Well, not _many_ people, anyway.) I would indeed support their deprecation - but perhaps in a separate docume= nt, as I'm concerned that any unnecessary delay with this one is another da= y that RC4's still actively being used by many, even when better alternativ= es are available - which is another day of traffic Eve can record - and, I = fear, break, now or any time later at their leisure. The sooner we can proceed, the sooner we can start working to fix that. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJULYUNAAoJEOyEjtkWi2t6cZYQAK/LJRHi9BjIDkyQgTGiSRrl D7tawBqIyR/0IErV+bz1UrIvCifx4Lrn99qscMEfuklRjEmJ0QJa2qAYYB51LPOi +zxphHrXwSA3iofgTqawPLq3A+N6mHM38TBKhhxRW8oF8Y7zcNtvIAFRAWZ3f5zM vAN9GW4MJLbDYpbu4mxsJ1qLhZ8+Ojo3IIcJnhhhZYJ6pdlwoQzWlUOzd9itdbbo Nn1DnZUvJBIHS8uGclFamZDlg+f4b4Djy6msQH1C2VdQkgaZxAHr/E+gaU/whpTY Qfc9FooyaEH5tpAiKDfcTjyhhgWatsJQhx39I+Mt/t9Ht+H7FR3kxHB4XRCgiSyg ASvobV/ATo3aSflqeUrO7myS7cJWXH2gHCVKCXIw0JxIT40j5q08VtUsd9b1Db9Z HaXWibvBYcngkGvpHC5CW+P7vNDP0x4wUPNaa/w8KBO7dZcqwFKC7BHpcekIKt4A yQjiPAG2tXDmqd5Y9GykcJU0kFZucPbulcGnNW1KeAoZhgBmUzsDVq0gw6U+VQ/J 1vFcwG2DlCl1ICBxHEjCcNAiJ3K0MX5Dz6wMD2NaQ1CvlqU3g7HWHJha0VbMsQns P1SLllT8Kjmm/KpJyqiYE0hbuYfWnUPv5BeKW5eVuBzZA2D8maHSBilIZIvPbv8K a1qiinNciHhRIs14X8kV =3DGfyS -----END PGP SIGNATURE----- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Oct 2 10:55:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCB11A90FB for ; Thu, 2 Oct 2014 10:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpFRqxIHqjqc for ; Thu, 2 Oct 2014 10:54:48 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824871A90F8 for ; Thu, 2 Oct 2014 10:54:48 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 826107BECD; Thu, 2 Oct 2014 19:54:46 +0200 (CEST) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 7582E4423B; Thu, 2 Oct 2014 19:54:46 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6EB7B1AEA6; Thu, 2 Oct 2014 19:54:46 +0200 (CEST) In-Reply-To: <20141002102602.3651570f@hboeck.de> To: =?ISO-8859-1?Q?Hanno_B=F6ck?= Date: Thu, 2 Oct 2014 19:54:46 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20141002175446.6EB7B1AEA6@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sqLifZp3BY5huDjOjd1vBeSnQvs Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:54:58 -0000 Hanno B=F6ck wrote: >=20 > I really don't want to hold anything here and would welcome if this > gets finally out, however there's one thing that bothers me: > There is currently no such RFC for RC2 or DES. Both are - considering > current RFCs - perfectly valid ciphers according to RFC 2246. >=20 > It doesn't really make sense to forbid RC4 (likely weak, but no > public practical attacks yet) while still allowing RC2(40 bit)/DES > (practically broken). not quite. TLS cipher suites with three symmetric encryption algorithms that are described in the TLSv1.1 spec (rfc4346) no longer appear in TLSv1.2 (rfc5246): RC2, (single-)DES, and IDEA For two of these three TLS cipher(suites), a seperate RFC was issued: http://tools.ietf.org/html/rfc5469 RC2 may have been left out since it existed only as RC2-40 in SSLv3&TLS. I prefer the rfc5469 approach by a significant margin over the science-defying dogmatic, radical extremist approach of the rc4 I-D. Attacking a single-DES TLS session is *VERY* practical. Attacking a dozen RC4-encrypted TLS-sessions is infeasible based on all that we currently know. -Martin From nobody Thu Oct 2 12:13:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341A11A1B7E for ; Thu, 2 Oct 2014 12:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnfNLE5bXmjn for ; Thu, 2 Oct 2014 12:13:11 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC74F1A1B4F for ; Thu, 2 Oct 2014 12:13:10 -0700 (PDT) Received: from mail-yh0-f49.google.com (mail-yh0-f49.google.com [209.85.213.49]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0MSao8-1XhVZI2cSK-00RcAs; Thu, 02 Oct 2014 21:13:08 +0200 Received: by mail-yh0-f49.google.com with SMTP id a41so465720yho.22 for ; Thu, 02 Oct 2014 12:13:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.140.97 with SMTP id d61mr1210232yhj.164.1412277186430; Thu, 02 Oct 2014 12:13:06 -0700 (PDT) Received: by 10.170.194.15 with HTTP; Thu, 2 Oct 2014 12:13:06 -0700 (PDT) In-Reply-To: <542D850E.2060900@akr.io> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> Date: Thu, 2 Oct 2014 21:13:06 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=20cf303ea810058eb805047568e3 X-Provags-ID: V02:K0:RIBj4CUm/kU2q1H2QMV4NiFNHjgb/gP/dWoua5IyneS KpeeE/hw2ULgFOnNddkYpccF1nlbKMiuLFWocVatlZoTof1NMf azUzUEfsdD7OH19e7lw2IhOsbvc21J+/Ish635y9htzFxFbDsZ n9ax8WVLSs3Vr6h5l0aGkRQjkJS+c9tpE/xPvVtdXWgIZujYer N46nxvzXg88imNpVfYUir0BYBYPm4BYs4ZDQKz1w3rOfmjKfch nCrFrufogvaQd8k6XDo2MCl7Ae3RCXk2AFOnQyNc2kWijqOEsa szi4vzB2BA1pUNlW2UglVfFVWCEc9qpRX/avbUXcBJrhdiAXHR 56QYfR6NfiGB/5BSPLJb1YiRx9b56KzM0k5fSMIE15nFBXlQFA Kj/wQ239zAlvAe0JZpRwzKUehoUEPlpgAkt01DDaHoLkJLUIfI 1d/PS X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mjX_2QxvzNFWhoo52jMGz8i5F4c Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 19:13:12 -0000 --20cf303ea810058eb805047568e3 Content-Type: text/plain; charset=UTF-8 > > > Maybe the spec should have strict MUST NOT requirements for TLS > 1.2, but make mere recommendations for the legacy protocols? > > No, not sure I follow your reasoning here: If you're not using TLS 1.2 but an earlier protocol version, then obviously backwards compatibility is of concern (and there's really no non-crappy cipher suite available). It seems that you can get by without RC4 when using TLS 1.2, but obviously sites do still see a need to support RC4 with older protocol versions. Regarding obsolete ciphers such as RC2 and DES, I don't think the need > to prohibit them is quite as urgent, because people aren't actually > using them in the wild. (Well, not _many_ people, anyway.) > > I would indeed support their deprecation - but perhaps in a separate > document, as I'm concerned that any unnecessary delay with this one Fair enough. Bodo --20cf303ea810058eb805047568e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Maybe the spec should have strict MUST NOT requirements f= or TLS
> 1.2, but make mere recommendations for the legacy protocols?

No, not sure I follow your reasoning here:

If you're not using TLS 1.2 but an earlier protocol version, th= en obviously backwards compatibility is of concern (and there's really = no non-crappy cipher suite available). It seems that you can get by without= RC4 when using TLS 1.2, but obviously sites do still see a need to support= RC4 with older protocol versions.


Regarding obsolete ciphers such as RC2 and DES, I don't think the need<= br> to prohibit them is quite as urgent, because people aren't actually
using them in the wild. (Well, not _many_ people, anyway.)

I would indeed support their deprecation - but perhaps in a separate
document, as I'm concerned that any unnecessary delay with this one

Fair enough.

Bodo

--20cf303ea810058eb805047568e3-- From nobody Thu Oct 2 13:13:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A4C1A70FE for ; Thu, 2 Oct 2014 13:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwzvXP0ZNIU6 for ; Thu, 2 Oct 2014 13:13:22 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA171A86EB for ; Thu, 2 Oct 2014 13:13:09 -0700 (PDT) Message-ID: <542DB1D4.4020601@akr.io> Date: Thu, 02 Oct 2014 21:13:08 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: "tls@ietf.org" References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RMtn1PD5XiajIJ9p5mmsABBE4dU Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 20:13:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/10/2014 20:13, Bodo Moeller wrote: >> No, not sure I follow your reasoning here: > If you're not using TLS 1.2 but an earlier protocol version, then > obviously backwards compatibility is of concern (and there's > really no non-crappy cipher suite available). Then reasonable behaviour would be to choose the least weak cipher available that's still sort of acceptable¹? RC4 is not sort of acceptable. It's not even the least weak. > It seems that you can get by without RC4 when using TLS 1.2, but > obviously sites do still see a need to support RC4 with older > protocol versions. And this is _exactly_ the behaviour that we're warning needs to stop ASAP. This isn't some compatibility kludge. This is a weak cipher. ___ [1] And _definitely_ issue the fallback SCSV, in case you're being tricked into using weak with a new client when you could use strong. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJULbHUAAoJEOyEjtkWi2t68ssQAKx0jHP+sNjv5TrkOHUZqyqw WPikAVKj2t/rjOK62asCpPwrgq5H3SK1OVdAVoA+QHaQDQZfZvIs9XYuaKctbps8 fd6Sl91qnOXzrSnXXno79ujOFhshKJ8wU6eDJjo7Hpfo+FL2PVVB/GmfsZ/UQD7y ieQzsva+8lzD7bvDJ3AGQ6Pp0gKxUlihNmnFLoGWMNFXUOgMzMbmBzXxKi0Wck4N 2pP2gdgdYvfDkXxTGLrhjQj08eiSlCPnz42NW4GPlA9U1piW0ugOV4ZDusvaSAFW tHznRfv1RhJl4K85vl0AKGjlAUFcoP2j+N3uQek65ksw/1LoUUlpDtLIj1//et4r 4WThorRRHwni7UohxLBP2QC558evu+Gsl4gYvuMhcjOWdE5GazM6777rocKOThYV LOhaaR5OZpuQk6BXa8K6Uvdj029DgAstFIYM7QulyXbOBYzMV00DBTcDgJmzHjul B+XxpqvuQCMA9kufdWFcXvOnBxlgaqFnjiGRO5GH3fvIgPCVqkYvfnO2NS4qLHMe OvBmYWz22lR+w8/p6OQIttxw/DoRPPzXlCnljZWOLmAlocdOrmT7zyVPcan7iGR+ jfTQNiZ9SJyjXQs41kYaoJbTKJrDK+LAL7kwQkWUpFuIYaMLHZPyxMo+QlNN1W9L dTj4k3+yRjX8BX6NIqmG =3Wem -----END PGP SIGNATURE----- From nobody Thu Oct 2 14:23:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7EE1ACDA3 for ; Thu, 2 Oct 2014 14:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsihjANZAhBz for ; Thu, 2 Oct 2014 14:22:58 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17D51ACDA0 for ; Thu, 2 Oct 2014 14:22:57 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id cc10so5377075wib.13 for ; Thu, 02 Oct 2014 14:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QAltd6H+cyd6dmZ/nIZMpyyvf0XRLho0kd1MrpRwLGI=; b=WFbI6YjMZjBqdYy+M+NiqLigtCevW/dW5+ePNgnac558w8NcdBU/guHR2TuXAgBcHx x1+qMuLt3D3OwHlSrYMuMoBoXGg338qwkjwFTxm9Rbf3UFD7ABrsyT/9etoM1y6SND4B aV62aHMRu/n8gTtu1XBJRUTf1JN8C9+9tt2NiGt2TAh65RIDX6sSGAWq6moKldQk4BNf wDmAV7HXjOCe7lMMUuKhfKroT7dgAKdWMacDI2nsk7fOhzzdLmTuLxXJMqmlW7F6Y8KQ aw5o2JagHsAwJXHVkkv4lpjFEWD69N5b02d6tAncfk0ygDLv6IGdxIsjuNWA4258Ad3D GV1g== X-Received: by 10.194.57.5 with SMTP id e5mr1771321wjq.128.1412284976324; Thu, 02 Oct 2014 14:22:56 -0700 (PDT) Received: from [192.168.1.100] (IGLD-84-228-54-144.inter.net.il. [84.228.54.144]) by mx.google.com with ESMTPSA id be1sm2491870wib.4.2014.10.02.14.22.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 14:22:55 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <1412255992.27112.41.camel@dhcp-2-127.brq.redhat.com> Date: Fri, 3 Oct 2014 00:22:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <039F1A93-7C77-45B0-87CA-33E0916FDB35@gmail.com> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <1412253233.27112.31.camel@dhcp-2-127.brq.redhat.com> <73B75C67-2608-4210-A624-14934E08016E@gmail.com> <1412255992.27112.41.camel@dhcp-2-127.brq.redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IorKWAStNTbuf74t1hEVzL3AkVY Cc: "tls@ietf.org" Subject: Re: [TLS] adopting ChaCha20 as a WG item was: I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:22:59 -0000 On Oct 2, 2014, at 4:19 PM, Nikos Mavrogiannopoulos = wrote: > On Thu, 2014-10-02 at 15:58 +0300, Yoav Nir wrote: >> Hi, Nikos >>=20 >> I think yes, especially considering that CFRG has just started RGLC = on >> the document. >>=20 >> I think it=92s debatable whether we need so many ciphersuites. >> Considering that TLS 1.3 will be PFS-only and AEAD-only, I=92m not = sure >> we need the ciphersuites in section 4.1, and the RSA (without DHE) >> ciphersuites. The feedback I got in IPsecME was that we didn=92t need >> anything but the AEAD. But that kind of thing can be debated in the >> working group. >=20 > Hello Yaov, > I agree. The non-AEAD ciphersuites are in order to be implementable to > pre-TLS 1.2. Whether they are applicable to TLS 1.3 or not, is outside > the scope of this document. >=20 HI Nikos A pre-1.2 implementation of ChaCha20 assumes that there are libraries = out there that on the one hand don=92t have TLS 1.2, and on the other = hand are still actively developed enough that they will implement a new = algorithm. I don=92t think that=92s the case. If ChaCha20-Poly1305 is going to be = implemented in OpenSSL, it=92s going to be in 1.0.1 or 1.0.2. I don=92t = think anyone=92s going to add it to 0.9,8, where every recent patch has = been a security hotfix. Similarly, every library I know of that is being maintained already has = TLS 1.2. I don=92t feel strongly about it, but I don=92t see the use of = having new non-AEAD ciphers at this point. Yoav From nobody Thu Oct 2 19:05:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00441ACFD8 for ; Thu, 2 Oct 2014 19:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6EAOOuoENXF for ; Thu, 2 Oct 2014 19:05:52 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22EE01ACFD7 for ; Thu, 2 Oct 2014 19:05:52 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 0368033D08C; Fri, 3 Oct 2014 02:05:50 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Andrei Popov References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <64cfd9c21a3f430287b7a0d30908b007@BL2PR03MB419.namprd03.prod.outlook.com> From: Geoffrey Keating Date: 02 Oct 2014 19:05:50 -0700 In-Reply-To: <64cfd9c21a3f430287b7a0d30908b007@BL2PR03MB419.namprd03.prod.outlook.com> Message-ID: Lines: 44 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/tls/o5jOhhHNB2V3iWucohQHkhZh4gE Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 02:05:55 -0000 Andrei Popov writes: > 2. "TLS servers MUST NOT select an RC4 cipher suite" is too > strict/constraining/hard to deploy/etc. > If we removed this MUST NOT, this would not be a prohibiting-rc4 > draft, but a best practice recommendation. We have TLS-BCP for > recommendations. The idea of prohibiting-rc4 is to completely remove > a weak cipher suite. I support this, and especially the logic behind it. > 3. But there are other weak cipher suites: EXPORT, DES, RC2, MD5... > Totally agree; these need to be removed as well. However, we've been > discussing prohibiting-rc4 for over a year now. I think we should > let this draft proceed so that we can make some progress. I don't > mind authoring a new I-D (or I-Ds) prohibiting EXPORT, DES, RC2, MD5 > ciphers. I support this and the logic behind it too. I would also support creating a new I-D. TLS 1.1 already says about the EXPORT ciphersuites: TLS 1.1 implementations MUST NOT negotiate these [EXPORT] cipher suites in TLS 1.1 mode. However, for backward compatibility they may be offered in the ClientHello for use with TLS 1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the server did not choose one of these cipher suites during the handshake. RFC 5469 says that for DES and IDEA, If a TLS library implements these cipher suites, it SHOULD NOT enable them by default. Experience has also shown that rarely used code is a source of security and interoperability problems, so existing implementations SHOULD consider removing these cipher suites. which is a bit less then the absolute prohibition I'd like, and not all implementations have actually disabled these ciphers---indeed some servers in the wild will still negotiate these ciphersuites, particularly TLS_RSA_WITH_DES_CBC_SHA. We don't seem to have anything about MD5. From nobody Thu Oct 2 21:24:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7045B1ACFDC for ; Thu, 2 Oct 2014 21:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqaU6Eh9Sv1W for ; Thu, 2 Oct 2014 21:24:20 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978001ACFDB for ; Thu, 2 Oct 2014 21:24:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4CA662AAC96; Fri, 3 Oct 2014 04:24:18 +0000 (UTC) Date: Fri, 3 Oct 2014 04:24:18 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20141003042418.GS13254@mournblade.imrryr.org> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542DB1D4.4020601@akr.io> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ahU0QonBDlfNo1GpSlPy-2cMM3c Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 04:24:22 -0000 On Thu, Oct 02, 2014 at 09:13:08PM +0100, Alyssa Rowan wrote: > RC4 is not sort of acceptable. When draft becomes an RFC, it will be widely ignored. For interoperability reasons, many applications will sensibly continue to support RC4 ciphers. The MUST will have no more effect than a SHOULD, the latter is all that can be justified at this time. Mostly all we need is an end to servers preferring RC4 and overriding the client ciphersuite preference order, and an end to clients preferring RC4 over stronger options. Which leaves RC4 in use only when no stronger options are available. While we're debating this, Google (for example) is still today blithely ignoring the RC4 deprecation. Their outbound SMTP client prefers RC4 over all other bulk crypto algorithms: Oct 2 02:12:30 ... TLS connection established from mail-oi0-f63.google.com[209.85.218.63]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) Oct 2 15:14:52 ... TLS connection established from mail-ie0-f180.google.com[209.85.223.180]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) Oct 2 15:21:49 ... TLS connection established from mail-lb0-f192.google.com[209.85.217.192]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) Oct 2 15:28:26 ... TLS connection established from mail-ig0-f192.google.com[209.85.213.192]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) Oct 2 15:46:09 ... TLS connection established from mail-qc0-f187.google.com[209.85.216.187]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) Oct 2 22:29:06 ... TLS connection established from mail-qc0-f178.google.com[209.85.216.178]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) Oct 3 00:10:20 ... TLS connection established from mail-lb0-f180.google.com[209.85.217.180]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) Oct 3 01:44:04 ... TLS connection established from mail-pa0-f53.google.com[209.85.220.53]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) Oct 3 03:41:55 ... TLS connection established from mail-pd0-f178.google.com[209.85.192.178]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) Many others are likely to continue ignoring impractical advice. A more realistic document is I think likely to see greater adoption. Recall that most applications are choosing RC4 over stronger options through explicit operator configuration that no application or SSL/TLS toolkit can reasonably override. So in the final analysis, the same degree of operator indifference will follow from either a MUST or a SHOULD. Solving the problem in practice, rather than in theory, means server software and perhaps hardware upgrades (on systems with no AESNI or similar support). Various BCP documents, product tutorials, ... will need to be updated to discourage preference for the previously popular RC4. So documents that mandate disabling RC4 in TLS 1.0 and/or SSL 3.0 are mere security theatre. The theatre piece that comes to mind is the Mikado: Ko-Ko: When Your Majesty says "Let a thing be done", it's as good as done, practically it is done, because Your Majesty's will is law. Your Majesty says "Kill a gentleman", and the gentleman is to be killed, consequently that gentleman is as good as dead, practically he is dead, and if he is dead, why not say so? The Mikado: I see. (Dramatic Pause) Nothing could possibly be more...satisfactory! It is of course far more reasonable for toolkits to disable RC4 and similarly weak or weaker ciphers with TLS >= 1.2 and negotiate only lower protocol versions when this leaves no ciphers available. Presumably with TLS 1.2 both client and server can employ AES-GCM to avoid both CBC and RC4 issues. Such a strategy would actually mean that RC4 begins to disappear sooner, because this could be implemented in toolkits, and could reasonably trump server policy. Or we can pretend that operators will care that some RFC says MUST NOT use RC4. -- Viktor. From nobody Fri Oct 3 00:02:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679C51ACF88 for ; Fri, 3 Oct 2014 00:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5Zs6jLcj5UH for ; Fri, 3 Oct 2014 00:02:03 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7A11A886D for ; Fri, 3 Oct 2014 00:02:03 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 131so166747ykp.27 for ; Fri, 03 Oct 2014 00:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Jm42ZNiLd/Tqgvs9bKht2slnPID2glvOvP1fkZhaKoM=; b=cs+nESo3w+iyjOtJ8BThhsLWSl9fMVLA2uVXfWtxivzVqK0pNgH84wd0YlXVODIdTK pY1njLBJIx1zm8QVYpf73TKhlqdm+XvZR1l7dT4k8c1NulDm+ZUvhtx2fsqsfHMXsofz YEJv4jeXOu6t7IvQosl+3NTE96oxr8nqYT/vXG+zwsjpKw+kr6blorwrIJdXufbo4hjs V4aG4Iy1xhjInMg3pONwPxOQrljK0QlobW4uLBQtOdMqGaEo5vfIa506H3X+4UJqkv45 9c2jneeBKlaRmlPyaU72WBAvF8nSPcPiDb53vXkNTGcGopYRcR42nPa1/MnLhRtRkdmK ynaA== MIME-Version: 1.0 X-Received: by 10.236.231.178 with SMTP id l48mr5141118yhq.143.1412319722616; Fri, 03 Oct 2014 00:02:02 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Fri, 3 Oct 2014 00:02:02 -0700 (PDT) In-Reply-To: <20141003042418.GS13254@mournblade.imrryr.org> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> Date: Fri, 3 Oct 2014 00:02:02 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WM-0epqWfDnNlvanQT5htX8YqkM Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 07:02:05 -0000 On Thu, Oct 2, 2014 at 9:24 PM, Viktor Dukhovni wrote: > On Thu, Oct 02, 2014 at 09:13:08PM +0100, Alyssa Rowan wrote: > >> RC4 is not sort of acceptable. > > When draft becomes an RFC, it will be widely ignored. For > interoperability reasons, many applications will sensibly continue > to support RC4 ciphers. The MUST will have no more effect than a > SHOULD, the latter is all that can be justified at this time. > > Mostly all we need is an end to servers preferring RC4 and overriding > the client ciphersuite preference order, and an end to clients > preferring RC4 over stronger options. Which leaves RC4 in use only > when no stronger options are available. > > While we're debating this, Google (for example) is still today > blithely ignoring the RC4 deprecation. Their outbound SMTP client > prefers RC4 over all other bulk crypto algorithms: > > Oct 2 02:12:30 ... TLS connection established from mail-oi0-f63.google.com[209.85.218.63]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) > Oct 2 15:14:52 ... TLS connection established from mail-ie0-f180.google.com[209.85.223.180]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) > Oct 2 15:21:49 ... TLS connection established from mail-lb0-f192.google.com[209.85.217.192]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) > Oct 2 15:28:26 ... TLS connection established from mail-ig0-f192.google.com[209.85.213.192]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) > Oct 2 15:46:09 ... TLS connection established from mail-qc0-f187.google.com[209.85.216.187]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) > Oct 2 22:29:06 ... TLS connection established from mail-qc0-f178.google.com[209.85.216.178]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) > Oct 3 00:10:20 ... TLS connection established from mail-lb0-f180.google.com[209.85.217.180]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) > Oct 3 01:44:04 ... TLS connection established from mail-pa0-f53.google.com[209.85.220.53]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) > Oct 3 03:41:55 ... TLS connection established from mail-pd0-f178.google.com[209.85.192.178]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits) > > Many others are likely to continue ignoring impractical advice. > A more realistic document is I think likely to see greater adoption. Let's be 100% clear here: RC4 is not required for interoperability, as TLS 1.0, 1.1, and 1.2 all specify other MTI suites for interop. Disabling RC4 is possible. It needs to be disabled, whether by no longer offering it or administrator action. The Lucky 13 and BEAST attacks require either client "features" and are mostly patched anyway. > > Recall that most applications are choosing RC4 over stronger options > through explicit operator configuration that no application or > SSL/TLS toolkit can reasonably override. > > So in the final analysis, the same degree of operator indifference > will follow from either a MUST or a SHOULD. Solving the problem > in practice, rather than in theory, means server software and > perhaps hardware upgrades (on systems with no AESNI or similar > support). Various BCP documents, product tutorials, ... will need > to be updated to discourage preference for the previously popular > RC4. > > So documents that mandate disabling RC4 in TLS 1.0 and/or SSL 3.0 > are mere security theatre. The theatre piece that comes to mind > is the Mikado: Aren't these the documents that will precisely "discourage preference for the previously popular RC4"? It seems to me that you are arguing for SHOULD so that RC4 can continue to be used, having conceded it shouldn't be. Every complaint you make that MUST will end the use of RC4 is exactly a reason to do it. I don't see how a SHOULD is more likely to lead to action than a MUST. > > Ko-Ko: When Your Majesty says "Let a thing be done", it's as > good as done, practically it is done, because Your Majesty's > will is law. Your Majesty says "Kill a gentleman", and the > gentleman is to be killed, consequently that gentleman is as > good as dead, practically he is dead, and if he is dead, why > not say so? > > The Mikado: I see. (Dramatic Pause) Nothing could possibly be > more...satisfactory! > > It is of course far more reasonable for toolkits to disable RC4 > and similarly weak or weaker ciphers with TLS >= 1.2 and negotiate > only lower protocol versions when this leaves no ciphers available. > Presumably with TLS 1.2 both client and server can employ AES-GCM > to avoid both CBC and RC4 issues. > > Such a strategy would actually mean that RC4 begins to disappear > sooner, because this could be implemented in toolkits, and could > reasonably trump server policy. Why is this more reasonable than disabling RC4 for all protocol versions where an alternative cipher exists/is offered and patching Lucky13+BEAST? (There is also the alternative of enabling the new extensions: I think we should ask what the path forward for TLS 1.1 is: migration or maintain forever?) Why can this trump server policy, but preferring AES in all version can't? > > Or we can pretend that operators will care that some RFC says MUST > NOT use RC4. They will care when the pentester points it out to their boss. Sincerely, Watson Ladd > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Oct 3 02:20:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193CE1AD003 for ; Fri, 3 Oct 2014 02:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZki1YF_OUKO for ; Fri, 3 Oct 2014 02:20:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E01E1ACFFA for ; Fri, 3 Oct 2014 02:20:49 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s939KkAF017850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 3 Oct 2014 05:20:46 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s939Ki2q031071 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2014 05:20:45 -0400 Message-ID: <1412328043.6317.29.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Yoav Nir Date: Fri, 03 Oct 2014 11:20:43 +0200 In-Reply-To: <039F1A93-7C77-45B0-87CA-33E0916FDB35@gmail.com> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <1412253233.27112.31.camel@dhcp-2-127.brq.redhat.com> <73B75C67-2608-4210-A624-14934E08016E@gmail.com> <1412255992.27112.41.camel@dhcp-2-127.brq.redhat.com> <039F1A93-7C77-45B0-87CA-33E0916FDB35@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bqSNjuMvi0AisB0Tvy0QZMsBpts Cc: "tls@ietf.org" Subject: [TLS] why Chacha20-SHA1 was: adopting ChaCha20 as a WG item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 09:20:51 -0000 On Fri, 2014-10-03 at 00:22 +0300, Yoav Nir wrote: > HI Nikos > > A pre-1.2 implementation of ChaCha20 assumes that there are libraries > out there that on the one hand don’t have TLS 1.2, and on the other > hand are still actively developed enough that they will implement a new > algorithm. I don’t think that’s the case. If ChaCha20-Poly1305 is going > to be implemented in OpenSSL, it’s going to be in 1.0.1 or 1.0.2. I > don’t think anyone’s going to add it to 0.9,8, where every recent patch > has been a security hotfix. Similarly, every library I know of that is > being maintained already has TLS 1.2. I don’t feel strongly about it, > but I don’t see the use of having new non-AEAD ciphers at this point. There have been quite some discussions about that with the TLS WG chairs as well. I'll provide my point of view here. The need for an alternative to Poly1305 hash is for redundancy and being conservative when introducing a new hash (we always had HMAC-SHA1 in addition to HMAC-MD5). The need for using a compatible with TLS 1.0/1.1 design is implementation simplicity, and definition simplicity. I elaborate below. There are several market segments. Some make products that last less than 2-3 years and after that they are obsolete and unmaintained. That market segment has the luxury to adopt new technologies quickly and ignore any issues on a 10 year old mobile phone for example. The market segment I work on makes products that are designed to last for 6+ years (often more than 10) and during that time they are maintained and get new security features whenever that's possible. While adding a new stream ciphersuite to TLS 1.0 or 1.1 is trivial, adding support for TLS 1.2 or AEAD is significant work with many potential side-effects and regressions, and that is something you don't do on a production system unless there is a real reason for that. This provides rationale why I feel that a backwards compatible with TLS 1.0 and TLS 1.1 ciphersuite is needed that can replace RC4. The other reason I believe that Chacha20-SHA1 is needed, is redundancy and backup. Poly1305 is a new MAC algorithm not used anywhere else, and having a conservative design along it, provides a reasonable fallback. Why this design uses the TLS stream authenticated encryption? because it is simpler and safer. The TLS stream authenticated encryption is a tried and proved construction that combines a MAC and a stream cipher. By going the AEAD path I'd have to play cryptographer and define a "novel" Chacha20-SHA1 design, anyway that I'd feel like, send it to IETF to standardize it as AEAD (possibly pass through CFRG as well), and few years later when it is obsolete add it to TLS. Then implementers would have, implement my special design and release. You could argue that I could specify it to be exactly the same as the stream authenticated-encryption and shortcut some of that path... Isn't that what I'm doing? If there was commonly accepted form of AEAD that would allow to combine a stream cipher and a MAC, that would change things, but there isn't. regards, Nikos From nobody Fri Oct 3 02:38:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18051AD002 for ; Fri, 3 Oct 2014 02:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6-i3papVvNn for ; Fri, 3 Oct 2014 02:38:08 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F691A0233 for ; Fri, 3 Oct 2014 02:38:07 -0700 (PDT) Received: from tunnis-2.local (unknown [62.80.223.85]) by mail.frobbit.se (Postfix) with ESMTPSA id D844222E87; Fri, 3 Oct 2014 11:38:05 +0200 (CEST) Message-ID: <542E6E7C.90204@secworks.se> Date: Fri, 03 Oct 2014 11:38:04 +0200 From: =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <1412253233.27112.31.camel@dhcp-2-127.brq.redhat.com> <73B75C67-2608-4210-A624-14934E08016E@gmail.com> <1412255992.27112.41.camel@dhcp-2-127.brq.redhat.com> <039F1A93-7C77-45B0-87CA-33E0916FDB35@gmail.com> <1412328043.6317.29.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1412328043.6317.29.camel@dhcp-2-127.brq.redhat.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vRyEqTxSB2C4wVjMkxilNW9lOFA Cc: "tls@ietf.org" Subject: Re: [TLS] why Chacha20-SHA1 was: adopting ChaCha20 as a WG item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: joachim@secworks.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 09:38:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aloha! Nikos Mavrogiannopoulos wrote: > There have been quite some discussions about that with the TLS WG > chairs as well. I'll provide my point of view here. The need for an > alternative to Poly1305 hash is for redundancy and being conservative > when introducing a new hash (we always had HMAC-SHA1 in addition to > HMAC-MD5). The need for using a compatible with TLS 1.0/1.1 design > is implementation simplicity, and definition simplicity. I elaborate > below. Would it be possible to at least use SHA256 instead of SHA-1? Adding a new suite that uses SHA-1 in 2015-2016 doesn't look good. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim@secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJULm58AAoJEF3cfFQkIuyNK54QAJYluAbI0QI7vRmIrIUMPF6X MTbFb2bckuyYnV1g4s6IH6LXvDkcf7Ugi8wjMbCOXMmQ9KziMS6hGDbdmDbuQDoE 6YtAyUYM+WwUMVV3cYhXOccPmWh61BEZY3Tqh6QRr7uwFnwNLUhlLe+ST6vfxMVg gFY28PR9/ELJ3gTuo+tz8KxeJ+WyX4u1jVODtxRECTKVZvz7i6tX7gWSU9RPidME WDHQW1Vtuv1tl99fjaNpSOpNtPjwRwRSNItwK494Ips2cSo5Kut60Ka5RQqfNc1T qrPghGBoqsnaEXpPNxb6+S25OAVRI1edqMdoNnRIkRgM7OqVN8uMHZFasIs3Ym02 QD0FaVVtfx8BJhER76rWO2OR1d6tRfZqH4hUvlSH0pa+N7SZ1KEFV86u6dl9h9E7 M9nrU/Uegt6QEBBGx2p6yIo4jMPSW04m6D+GLyN+bY/+7JFSXh6MQ7ah8u0CLVkM TLgDzjh0XOK6E9jhxjDTh/aMiXTw11aeCRgpvVLCCFBCkCmD0aYCVj8XSppjCVZF OhxZkalVsq2z8MhIhQMlWjQcejaMkF5cozweAK49Od9bYcp1u9iHf7IgF3vknncC zp2BVX+mhbk0eIo7PDMxJ7V5gQWt4h2JIdS8/VKejnqhsaMXWbPKjgJ+0IBYK6US MbBDSOMbzpSLyFoLU3Xm =BfFf -----END PGP SIGNATURE----- From nobody Fri Oct 3 03:12:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B661AD01F for ; Fri, 3 Oct 2014 03:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smHoZoA4EXAm for ; Fri, 3 Oct 2014 03:12:22 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BF91A020B for ; Fri, 3 Oct 2014 03:12:22 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id cc10so6721954wib.1 for ; Fri, 03 Oct 2014 03:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cm99Vsz9mu2UV3TY0D2DA2RN1j14ooLxA+JwqbPoTeE=; b=jnOvCqawer647erTJOc6wgZD4L3vCfm+6MMrZEd3oU7iv73ICGWQnnt8pxPcSQIOnb toauW5bpN1AnC770rAxVOaJqfRKvtgH9uGOnuoiD+xqZ5Mci2SpkMw3RlO4XOTJ6MuYZ fG9CEdXwoG6U3e9/O3S6bpn+N979NDk9LH+uhTNbm/56t1q5tVZJdE4SYmjhaJvxKPUI Wi+PhPjPSA2nC/MmAGnFGBUOmSl/gwcT9UCNCc5zfHHLmRtJLYTkDvgfV77AQbE8qH1Y xj3BLmn7r0i6QtBxrNztJZPr4t5DqfXEPoeFSA+1mychdLI8cU9/kQiwEjuxI0whTSbb bLvw== X-Received: by 10.194.84.42 with SMTP id v10mr5999658wjy.63.1412331141125; Fri, 03 Oct 2014 03:12:21 -0700 (PDT) Received: from [192.168.1.100] (IGLD-84-228-54-144.inter.net.il. [84.228.54.144]) by mx.google.com with ESMTPSA id f7sm1582468wix.22.2014.10.03.03.12.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Oct 2014 03:12:20 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_926B51B2-5D42-4A78-A0FA-E2E37BB88D11" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Fri, 3 Oct 2014 13:12:17 +0300 Message-Id: <6E575192-4AB2-4BF1-82AD-4008397CE41F@gmail.com> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> To: Watson Ladd X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zuJ8syOMidTly4sbxhf6d1lNrME Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 10:12:24 -0000 --Apple-Mail=_926B51B2-5D42-4A78-A0FA-E2E37BB88D11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 3, 2014, at 10:02 AM, Watson Ladd wrote: >> Many others are likely to continue ignoring impractical advice. >> A more realistic document is I think likely to see greater adoption. >=20 > Let's be 100% clear here: RC4 is not required for interoperability, as > TLS 1.0, 1.1, and 1.2 all specify other MTI suites for interop. Not required for interoperability with RFCs, but is required for = interoperability with real servers: http://securitypitfalls.wordpress.com/author/hkario/ 18% prefer RC4 to all others, while just under 1% support nothing else. = This may be because a lot of people configured RC4 only in the wake of = the BEAST attack, but regardless: if your browser has no RC4, it can=92t = browse all of the Internet. Yoav --Apple-Mail=_926B51B2-5D42-4A78-A0FA-E2E37BB88D11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Oct 3, 2014, at 10:02 AM, Watson = Ladd <watsonbladd@gmail.com> = wrote:

<snip />

Many = others are likely to continue ignoring impractical advice.
A more = realistic document is I think likely to see greater = adoption.

Let's be 100% clear here: RC4 is not = required for interoperability, as
TLS 1.0, 1.1, and 1.2 all specify = other MTI suites for = interop.

Not required = for interoperability with RFCs, but is required for interoperability = with real servers:

18% = prefer RC4 to all others, while just under 1% support nothing else. This = may be because a lot of people configured RC4 only in the wake of the = BEAST attack, but regardless: if your browser has no RC4, it can=92t = browse all  of the = Internet.

Yoav

= --Apple-Mail=_926B51B2-5D42-4A78-A0FA-E2E37BB88D11-- From nobody Fri Oct 3 04:15:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486CF1AD035 for ; Fri, 3 Oct 2014 04:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.687 X-Spam-Level: X-Spam-Status: No, score=-7.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zjAh-vEyIRk for ; Fri, 3 Oct 2014 04:15:15 -0700 (PDT) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC841A02D6 for ; Fri, 3 Oct 2014 04:15:15 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s93BFEqK008056 for ; Fri, 3 Oct 2014 07:15:14 -0400 Date: Fri, 3 Oct 2014 07:15:14 -0400 (EDT) From: Hubert Kario To: tls@ietf.org Message-ID: <1878200851.5790803.1412334914571.JavaMail.zimbra@redhat.com> In-Reply-To: <20141003042418.GS13254@mournblade.imrryr.org> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922) Thread-Topic: I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt Thread-Index: 2eY6vjuQd3w7ZQi9paqkgSL+ObxqPA== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YYDAjFEcsZBcFIQ-AXtHB4EPzZM Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 11:15:17 -0000 ----- Original Message ----- > From: "Viktor Dukhovni" > To: tls@ietf.org > Sent: Friday, 3 October, 2014 6:24:18 AM > Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt > > On Thu, Oct 02, 2014 at 09:13:08PM +0100, Alyssa Rowan wrote: > > > RC4 is not sort of acceptable. > > While we're debating this, Google (for example) is still today > blithely ignoring the RC4 deprecation. Their outbound SMTP client > prefers RC4 over all other bulk crypto algorithms: This is also the case for youtube video servers. Doesn't make it a good idea because it makes it impossible for web clients to drop RC4... > Recall that most applications are choosing RC4 over stronger options > through explicit operator configuration that no application or > SSL/TLS toolkit can reasonably override. This is not the case. Only about 1% of servers support only RC4 cipher, 1.5% if you're using Firefox[1]. On the other hand, over 21% of servers will negotiate a RC4 cipher in case you're using Firefox (and nearly 18% if you're using OpenSSL-like supported cipher list). So by dropping RC4 from your first ClientHello (in case you do use fallback) may as well cut your RC4 usage by over 20%! > So in the final analysis, the same degree of operator indifference > will follow from either a MUST or a SHOULD. Solving the problem > in practice, rather than in theory, means server software and > perhaps hardware upgrades (on systems with no AESNI or similar > support). Various BCP documents, product tutorials, ... will need > to be updated to discourage preference for the previously popular > RC4. Being able to point PHB to a RFC explicitly disallowing RC4 is a step in this direction. > It is of course far more reasonable for toolkits to disable RC4 > and similarly weak or weaker ciphers with TLS >= 1.2 and negotiate > only lower protocol versions when this leaves no ciphers available. > Presumably with TLS 1.2 both client and server can employ AES-GCM > to avoid both CBC and RC4 issues. 1). AES-128-CBC-SHA1 is faster than AES-GCM if you don't have hardware crypto acceleration, consequently RC4 is faster still 2). People still configure TLS1.1+ capable servers to prefer RC4 (over 12% to be exact[1]) We've been asking server operators not to do it for quite some time already. We need stronger arguments as they simply are not changing those configurations quickly enough. 1 - https://securitypitfalls.wordpress.com/2014/09/29/scan-results-for-september-2014/ -- Regards, Hubert Kario From nobody Fri Oct 3 04:27:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418CD1AD03B for ; Fri, 3 Oct 2014 04:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DlCoqus44dP for ; Fri, 3 Oct 2014 04:27:38 -0700 (PDT) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476341AD039 for ; Fri, 3 Oct 2014 04:27:38 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s93BRbtX009884 for ; Fri, 3 Oct 2014 07:27:37 -0400 Date: Fri, 3 Oct 2014 07:27:37 -0400 (EDT) From: Hubert Kario To: tls@ietf.org Message-ID: <1455759603.5793174.1412335657735.JavaMail.zimbra@redhat.com> In-Reply-To: <1878200851.5790803.1412334914571.JavaMail.zimbra@redhat.com> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> <1878200851.5790803.1412334914571.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922) Thread-Topic: I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt Thread-Index: 2eY6vjuQd3w7ZQi9paqkgSL+ObxqPG2SZRTM Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wsBXgwBejEtKniDOBTWDh_w9Dv4 Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 11:27:40 -0000 ----- Original Message ----- > From: "Hubert Kario" > To: tls@ietf.org > Sent: Friday, 3 October, 2014 1:15:14 PM > Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt > > ----- Original Message ----- > > From: "Viktor Dukhovni" > > To: tls@ietf.org > > Sent: Friday, 3 October, 2014 6:24:18 AM > > Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt > > > > On Thu, Oct 02, 2014 at 09:13:08PM +0100, Alyssa Rowan wrote: > > > > > RC4 is not sort of acceptable. > > > > Recall that most applications are choosing RC4 over stronger options > > through explicit operator configuration that no application or > > SSL/TLS toolkit can reasonably override. > > This is not the case. > > Only about 1% of servers support only RC4 cipher, 1.5% if you're > using Firefox[1]. > > On the other hand, over 21% of servers will negotiate a RC4 cipher > in case you're using Firefox (and nearly 18% if you're using > OpenSSL-like supported cipher list). > > So by dropping RC4 from your first ClientHello (in case you do use > fallback) may as well cut your RC4 usage by over 20%! One more thing, it's not really changing for the better: https://securitypitfalls.wordpress.com/2014/09/23/tls-landscape/ scroll to "Bad recommendations", or see this graph: https://securitypitfalls.files.wordpress.com/2014/09/rc4-preferral.png (that's "in general", for Firefox the situation is even worse) -- Regards, Hubert Kario From nobody Fri Oct 3 06:30:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3951A0AF1 for ; Fri, 3 Oct 2014 06:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INisJzrY43PD for ; Fri, 3 Oct 2014 06:30:46 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808121A1A2D for ; Fri, 3 Oct 2014 06:30:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BCCE32AB2A7; Fri, 3 Oct 2014 13:30:43 +0000 (UTC) Date: Fri, 3 Oct 2014 13:30:43 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20141003133043.GV13254@mournblade.imrryr.org> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qEVxDXrGEKj8LF9W28DxOtLDf0Q Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 13:30:47 -0000 On Fri, Oct 03, 2014 at 12:02:02AM -0700, Watson Ladd wrote: > > A more realistic document is I think likely to see greater adoption. > > Let's be 100% clear here: RC4 is not required for interoperability, as > TLS 1.0, 1.1, and 1.2 all specify other MTI suites for interop. In theory, but in practice it is. > Disabling RC4 is possible. It needs to be disabled, whether by no > longer offering it or administrator action. The Lucky 13 and BEAST > attacks require either client "features" and are mostly patched > anyway. A MUST NOT prefer RC4 is something one can realistically implement. A MUST NOT offer is something that many will be forced to ignore. An auditor can just as easily write findings about SHOULD NOT as MUST NOT. Documents that don't match operational reality are I think counter-productive. They eat away at the credibility of the standards body publishing the document. Before RC4 becomes MUST NOT, it needs to first become a low priority algorithm that is used when nothing better is available. With Exchange 2003 email servers that are still operating at some domains the only working ciphersuites are RC4-MD5 and RC4-SHA. Operators will ignore the IETF and leave RC4 enabled so that mail can continue to be sent to these domains. Note also that MTA to MTA mail transactions generally don't carry fixed sensitive text at a fixed position in the first 256 bytes of the client or server TLS stream. This is only an issue with submission when the client is using "AUTH PLAIN" or "AUTH LOGIN". I am strongly in favour of educating operators about the weakness of RC4, provided we give them operationally realistic advice. I don't see how MUST NOT is such advice. -- Viktor. From nobody Fri Oct 3 07:28:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B171A0023 for ; Fri, 3 Oct 2014 07:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZy0YIkLt_hV for ; Fri, 3 Oct 2014 07:28:54 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5681A000C for ; Fri, 3 Oct 2014 07:28:54 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id x13so1059010qcv.4 for ; Fri, 03 Oct 2014 07:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nAP9lolVT3zL93/95ogIPmgjO9MPCp+z2WuzHE0l9PY=; b=Q+PoTcSZsAyUT/59GxR4P0DUug7A2feJd92DI0vuOviCMgzgbiXtBHvoB9nZMDHQ7Y /IofR4nKYiiCpgNgr9QtIBpiUDgh8jH602COi27DWmZdcGVQbnx8jGj7IENdUg0f7bKw sI1FlmoP8Kxds0esyjBRvhkZrP4AVu7DwcsGlVNR3VQ6m1Hf67JOFQ1bf5+/nz6/6Jgj rzcVsWdzRUxmwvo+pPTcw/9PmO+VekO+oHvf0DymO1sbihVzXG+3hrAbzoD/0CXeIhXG 0BSVRBJXKsij9aForkBaBpgKQwZNv3GjpMDRVSw4Bam1QB97iqRdM+tb4jd/MMLYAerG S/KA== MIME-Version: 1.0 X-Received: by 10.224.80.131 with SMTP id t3mr7431982qak.35.1412346533848; Fri, 03 Oct 2014 07:28:53 -0700 (PDT) Received: by 10.140.20.199 with HTTP; Fri, 3 Oct 2014 07:28:53 -0700 (PDT) In-Reply-To: <20141003133043.GV13254@mournblade.imrryr.org> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> <20141003133043.GV13254@mournblade.imrryr.org> Date: Fri, 3 Oct 2014 07:28:53 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LCHqX05u7dFvnNj5eWldYCsVego Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 14:28:56 -0000 On Fri, Oct 3, 2014 at 6:30 AM, Viktor Dukhovni wrote: > On Fri, Oct 03, 2014 at 12:02:02AM -0700, Watson Ladd wrote: > >> > A more realistic document is I think likely to see greater adoption. >> >> Let's be 100% clear here: RC4 is not required for interoperability, as >> TLS 1.0, 1.1, and 1.2 all specify other MTI suites for interop. > > In theory, but in practice it is. > >> Disabling RC4 is possible. It needs to be disabled, whether by no >> longer offering it or administrator action. The Lucky 13 and BEAST >> attacks require either client "features" and are mostly patched >> anyway. > > A MUST NOT prefer RC4 is something one can realistically implement. > A MUST NOT offer is something that many will be forced to ignore. > An auditor can just as easily write findings about SHOULD NOT as > MUST NOT. > > Documents that don't match operational reality are I think > counter-productive. They eat away at the credibility of the > standards body publishing the document. > > Before RC4 becomes MUST NOT, it needs to first become a low priority > algorithm that is used when nothing better is available. What advice do you want to give them, and how will it end the use of RC4? The advice given is to not offer RC4 cipher suites on the client side, and not to pick them on the server side: are we only debating the third point? Or are you saying that clients should feel free to offer RC4, and servers should be configured to pick it last? Sincerely, Watson Ladd > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Oct 3 08:01:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4EC1A0120 for ; Fri, 3 Oct 2014 08:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLb1P4Bl_OqI for ; Fri, 3 Oct 2014 08:01:43 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E8F1A011B for ; Fri, 3 Oct 2014 08:01:30 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2E8E62AB2A7; Fri, 3 Oct 2014 15:01:29 +0000 (UTC) Date: Fri, 3 Oct 2014 15:01:29 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20141003150128.GX13254@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> <20141003133043.GV13254@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tZvW_lz74B14FxKSbKkdwAf7hVk Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:01:44 -0000 On Fri, Oct 03, 2014 at 07:28:53AM -0700, Watson Ladd wrote: > > Before RC4 becomes MUST NOT, it needs to first become a low priority > > algorithm that is used when nothing better is available. > > > What advice do you want to give them, and how will it end the use of > RC4? Use RC4 at a lower priority than any other non-deprecated 128-bit or better cipher suite or triple DES (which is rated at 168 bits by some libraries and 112 bits by others). There is no reason to prefer single-DES or any 40-bit export cipher suite over RC4. > The advice given is to not offer RC4 cipher suites on the client > side, and not to pick them on the server side: are we only debating > the third point? Or are you saying that clients should feel free to > offer RC4, and servers should be configured to pick it last? I am saying that initially (first step on the road to elimination) both clients and servers SHOULD choose RC4 last when it is not disabled. Clients and servers that implement mandatory security and prioritize security over interoperability SHOULD disable RC4 entirely. Clients and servers employing opportunistic unauthenticated encrypted communication SHOULD not disable RC4. Even RC4 is better than cleartext or communications failure, as it will only be chosen when no stronger options are available. -- Viktor. From nobody Fri Oct 3 09:25:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2C31A0387 for ; Fri, 3 Oct 2014 09:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjUpY9vOCJqJ for ; Fri, 3 Oct 2014 09:25:12 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D461A0384 for ; Fri, 3 Oct 2014 09:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1412353512; x=1443889512; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=9RPgEIy7RFM8QSp9IxmFIvpTmAew6KNd73PZtS7A1g8=; b=Bn30dfTjE0Q1v6/41Mzup1nedEjn5ddKwhY0k5jPgqlwbXlF8KZy92sq ZfozIINJFPDr5DGE/cWJVWWZHGUeSemL+PZ40Bl5EJYFlBDiiWhlpitgT pS+Nu9eDOkehIHkFE5gDLeTe/0n7RnOVfNqJgogSPk62j/H1D3p2pUJkb k=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="280240771" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 04 Oct 2014 05:25:07 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sat, 4 Oct 2014 05:25:07 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt Thread-Index: Ac/fJpeYqJWNhqq0Q+StElEGYEuZ3g== Date: Fri, 3 Oct 2014 16:25:06 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9C0CCC@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6PYKySpKEml8yI1HQQuYMOTh3go Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 16:25:16 -0000 Alyssa Rowan writes:=0A= =0A= >As I've pointed out, if you're forced into backwards compatibility with ru= sty=0A= >legacy, 3DES is, though crappy, a less crappy choice than RC4.=0A= >=0A= >As Rich points out, just because legacy devices are indeed out there doesn= 't=0A= >mean that they do TLS safely, and doesn't mean we shouldn't prohibit unsaf= e=0A= >practice like using weak ciphers.=0A= =0A= It's not just TLS implementations, you also need to look at the surrounding= =0A= infrastructure. For example Microsoft's NDES (Network Device Enrolment=0A= Service) hardcodes in MD5 to authenticate certs (via cert fingerprints) and= =0A= single DES (not 3DES, single DES) for "protection" of messages (even if you= =0A= send in a request using AES, the response comes back using single DES). In= =0A= other words the most modern algorithm in there is more than twenty years ol= d,=0A= and it's broken. So it doesn't matter how secure the TLS implementation is= if=0A= the certs used to control it are being "protected" with broken crypto.=0A= =0A= Peter.= From nobody Fri Oct 3 09:27:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97371A0391 for ; Fri, 3 Oct 2014 09:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEVUNk-FyJKx for ; Fri, 3 Oct 2014 09:27:01 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB0E1A0384 for ; Fri, 3 Oct 2014 09:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1412353621; x=1443889621; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=5lzcBV1AASwtZK1UcY50ZjdDg15iMpkg4Cy5CpEG710=; b=tb3N3hX4AKaxUB7GCQ/zl7Vm8Gm7EjCUWGGc73FsbgaMxnpIRyb/76ce ZJ0LGcaY1IsxkYcl1Xx8how5jsFPO9pw2zbvivPn9JIK2795EWl1wI9K6 N/YxS5KO4FfuzzksLBMY3V9gPtVIqJ+5WktJJ7pI6x8kc0wcrONhmykDv 4=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="280240893" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 04 Oct 2014 05:27:00 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Sat, 4 Oct 2014 05:27:00 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] AEAD only for TLS1.3 revisit Thread-Index: Ac/fJtrdNi50Jn1vR9ObGJtdlBGH9w== Date: Fri, 3 Oct 2014 16:26:59 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9C0CDC@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OO6c2Ic6qJ2RgpAEgGcycw0GA1I Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 16:27:03 -0000 "Salz, Rich" writes:=0A= =0A= >> (Hmm, come to think of it I never tried advertising TLS 1.2 when someone= =0A= >> asked for it but always falling back to 1.1, that would give "TLS 1.2" b= ut still=0A= >> interoperate with other implementations that hadn't got past 1.1).=0A= >=0A= >I'm shocked to hear that you never did that.=0A= =0A= I'm waiting for the TLS 1.3 bikeshedathon to finish so I can do it for that= :-).=0A= =0A= Peter.= From nobody Fri Oct 3 09:35:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A951A1A26 for ; Fri, 3 Oct 2014 09:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pmHTkVlYRgP for ; Fri, 3 Oct 2014 09:35:02 -0700 (PDT) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCBB1A19F4 for ; Fri, 3 Oct 2014 09:35:02 -0700 (PDT) Received: by mail-oi0-f44.google.com with SMTP id x69so1039666oia.31 for ; Fri, 03 Oct 2014 09:35:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cWYrMm6zyFiwc7C6HEfu3sPpLdP/JaQVqxz3Rd6NCNE=; b=Y4PZNJ0c+eE+jjOpcV6SFWqOjx0PysEj0Xg04J7coLdqj4Q6aYtaZ0JuIesEk5jWQw zfDzrOdrKzeLr27Ee/h01JZqEZuLl+oNVp/s5mUvmZgmPUdt7TrWZI4n6QMnqFIVVIa1 BpoEb+c6cyqz7RzNdnNLVGiNONFfyK0HHxKiWINTe5jb/y0tXnHh3TiJjljfcl4a8JJD JpPN6rxCnQjE4FSY6U2PZqVrQSQb7LNuZYWGlf9WhM0u73BVoUftBjXndujVkS2ZdjP4 dIQGBlv4ZX67Hu87vao9fUOmjhoQIxZbFrJ8aa3R4t1nFN+zHVYnAzXobXWoN+NILdfu FIeg== X-Gm-Message-State: ALoCoQlQUacu2HTAKbb4zm5VPash5z9DeEvLwq3NIjIoKBjVsTSIob6F2NfPOZSdf2DSKV+VyYlg MIME-Version: 1.0 X-Received: by 10.60.93.165 with SMTP id cv5mr8171906oeb.17.1412354101801; Fri, 03 Oct 2014 09:35:01 -0700 (PDT) Received: by 10.76.74.36 with HTTP; Fri, 3 Oct 2014 09:35:01 -0700 (PDT) In-Reply-To: <1412328043.6317.29.camel@dhcp-2-127.brq.redhat.com> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <1412253233.27112.31.camel@dhcp-2-127.brq.redhat.com> <73B75C67-2608-4210-A624-14934E08016E@gmail.com> <1412255992.27112.41.camel@dhcp-2-127.brq.redhat.com> <039F1A93-7C77-45B0-87CA-33E0916FDB35@gmail.com> <1412328043.6317.29.camel@dhcp-2-127.brq.redhat.com> Date: Fri, 3 Oct 2014 09:35:01 -0700 Message-ID: From: Brian Smith To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/StnjBxliv_LO1b7PK3u0QyF7e_k Cc: "tls@ietf.org" Subject: Re: [TLS] why Chacha20-SHA1 was: adopting ChaCha20 as a WG item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 16:35:04 -0000 Nikos Mavrogiannopoulos wrote: > On Fri, 2014-10-03 at 00:22 +0300, Yoav Nir wrote: >> HI Nikos >> >> A pre-1.2 implementation of ChaCha20 assumes that there are libraries >> out there that on the one hand don=E2=80=99t have TLS 1.2, and on the ot= her >> hand are still actively developed enough that they will implement a new >> algorithm. I don=E2=80=99t think that=E2=80=99s the case. If ChaCha20-Po= ly1305 is going >> to be implemented in OpenSSL, it=E2=80=99s going to be in 1.0.1 or 1.0.2= . I >> don=E2=80=99t think anyone=E2=80=99s going to add it to 0.9,8, where eve= ry recent patch >> has been a security hotfix. Similarly, every library I know of that is >> being maintained already has TLS 1.2. I don=E2=80=99t feel strongly abo= ut it, >> but I don=E2=80=99t see the use of having new non-AEAD ciphers at this p= oint. I agree with this. The ChaCha20-HMAC-SHA-1 cipher suite is not a good use of resources and should be removed so we can focus on other, more important, improvements. > The market segment I work on makes products that are designed to last > for 6+ years (often more than 10) and during that time they are > maintained and get new security features whenever that's possible. While > adding a new stream ciphersuite to TLS 1.0 or 1.1 is trivial, adding > support for TLS 1.2 or AEAD is significant work with many potential > side-effects and regressions, and that is something you don't do on a > production system unless there is a real reason for that. There are real reasons to add support for TLS 1.2 to stable products like RHEL (in particular). For example, versions less than 1.2 rely on the collision resistance of MD5 and SHA1, which really a bad idea. Further, nobody would be able to deploy HTTP/2 effectively (i.e. works with most browsers) without TLS 1.2, unless their products avoid the system crypto stack, which is counter to the purpose of having a system crypto stack in the first place. Consequently, I think it makes a lot more sense to spend time to figure out how to spread TLS 1.2 to these more conservative products and deployments, than it does to spend time figuring out how to avoid doing so. Further, why would any user that is too change-averse to deploy TLS 1.2 want to deploy ChaCha20 cipher suites? > The other reason I believe that ChaCha20-SHA1 is needed, is redundancy > and backup. Poly1305 is a new MAC algorithm not used anywhere else, and > having a conservative design along it, provides a reasonable fallback. We already have the AES-based cipher suites for fallback. > Why this design uses the TLS stream authenticated encryption? because it > is simpler and safer. The TLS stream authenticated encryption is a tried > and proved construction that combines a MAC and a stream cipher. By > going the AEAD path I'd have to play cryptographer and define a "novel" > Chacha20-SHA1 design, anyway that I'd feel like, send it to IETF to > standardize it as AEAD (possibly pass through CFRG as well), and few > years later when it is obsolete add it to TLS. You had to do the same thing for the stream construction. See https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-03#section-5 where you redefine the stream construction. > Then implementers would > have, implement my special design and release. Who is planning to implement ChaCha20-SHA1, regardless of how it is specified? I expect very few people to do so. Also, some newer implementations of TLS may not even implement the stream mode construction at all, since currently it is used only for RC4. This makes it even less likely that implementations will support the HMAC-SHA1 version. Cheers, Brian From nobody Fri Oct 3 09:37:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB881A1A77 for ; Fri, 3 Oct 2014 09:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir-KQ4GrBwSR for ; Fri, 3 Oct 2014 09:37:49 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5FA1A1A26 for ; Fri, 3 Oct 2014 09:37:49 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 10so467266ykt.0 for ; Fri, 03 Oct 2014 09:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OWiShbEk0KdP3L/gF7mM5Pt3EurZyNMfIHZOr9+hDHI=; b=o9GSztiIcdxQglQTT7GsCor9qTEWcy2keoRRBhs9Ts3VGZ3O/l0oam/LcAnFYadwxA eORdyU0Hj+0L7Yo8B6YXHrG7FOdyEJgNOUmhn1Rpa5ZjZw27z35ApygYY5nX/2JHxHAU LZo8MBHmxuSVSWwrUgMMgWOwehvv9Pnr2K7Rie3NyAydFtsTosz79dGLPqFGbfn5fQNX uvkfxkSa0aLT/foX7TJzpl+L79LKGSXdAugwoROazPz2+J34PUg6krBl3TvX71vENlKD jPfUJKWNuoOG9ERecrn1sM1XnffVAtTDO9y0Zq8U0go5Gp587eWBU8kg9KAw21dIHlx8 fKjQ== MIME-Version: 1.0 X-Received: by 10.236.172.161 with SMTP id t21mr9632314yhl.65.1412354268443; Fri, 03 Oct 2014 09:37:48 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Fri, 3 Oct 2014 09:37:48 -0700 (PDT) In-Reply-To: <1412328043.6317.29.camel@dhcp-2-127.brq.redhat.com> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <1412253233.27112.31.camel@dhcp-2-127.brq.redhat.com> <73B75C67-2608-4210-A624-14934E08016E@gmail.com> <1412255992.27112.41.camel@dhcp-2-127.brq.redhat.com> <039F1A93-7C77-45B0-87CA-33E0916FDB35@gmail.com> <1412328043.6317.29.camel@dhcp-2-127.brq.redhat.com> Date: Fri, 3 Oct 2014 09:37:48 -0700 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HOWt3uCQobDiln5utXV62xlPD54 Cc: "tls@ietf.org" Subject: Re: [TLS] why Chacha20-SHA1 was: adopting ChaCha20 as a WG item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 16:37:51 -0000 On Fri, Oct 3, 2014 at 2:20 AM, Nikos Mavrogiannopoulos w= rote: > On Fri, 2014-10-03 at 00:22 +0300, Yoav Nir wrote: > >> HI Nikos >> >> A pre-1.2 implementation of ChaCha20 assumes that there are libraries >> out there that on the one hand don=E2=80=99t have TLS 1.2, and on the ot= her >> hand are still actively developed enough that they will implement a new >> algorithm. I don=E2=80=99t think that=E2=80=99s the case. If ChaCha20-Po= ly1305 is going >> to be implemented in OpenSSL, it=E2=80=99s going to be in 1.0.1 or 1.0.2= . I >> don=E2=80=99t think anyone=E2=80=99s going to add it to 0.9,8, where eve= ry recent patch >> has been a security hotfix. Similarly, every library I know of that is >> being maintained already has TLS 1.2. I don=E2=80=99t feel strongly abo= ut it, >> but I don=E2=80=99t see the use of having new non-AEAD ciphers at this p= oint. > > There have been quite some discussions about that with the TLS WG chairs > as well. I'll provide my point of view here. The need for an alternative > to Poly1305 hash is for redundancy and being conservative when > introducing a new hash (we always had HMAC-SHA1 in addition to > HMAC-MD5). The need for using a compatible with TLS 1.0/1.1 design is > implementation simplicity, and definition simplicity. I elaborate below. Right conclusion: wrong reasons. Carter-Wegman MACs are unconditionally secure, but the code changes are minimized by reusing a MAC. Unfortunately the draft bobbles nonce handling: it's not clear to me how the nonce is generated in TLS 1.1 and TLS 1.0. > > There are several market segments. Some make products that last less > than 2-3 years and after that they are obsolete and unmaintained. That > market segment has the luxury to adopt new technologies quickly and > ignore any issues on a 10 year old mobile phone for example. > > The market segment I work on makes products that are designed to l > for 6+ years (often more than 10) and during that time they are > maintained and get new security features whenever that's possible. While > adding a new stream ciphersuite to TLS 1.0 or 1.1 is trivial, adding > support for TLS 1.2 or AEAD is significant work with many potential > side-effects and regressions, and that is something you don't do on a > production system unless there is a real reason for that. > > This provides rationale why I feel that a backwards compatible with TLS > 1.0 and TLS 1.1 ciphersuite is needed that can replace RC4. > > The other reason I believe that Chacha20-SHA1 is needed, is redundancy > and backup. Poly1305 is a new MAC algorithm not used anywhere else, and > having a conservative design along it, provides a reasonable fallback. > Why this design uses the TLS stream authenticated encryption? because it > is simpler and safer. The TLS stream authenticated encryption is a tried > and proved construction that combines a MAC and a stream cipher. By > going the AEAD path I'd have to play cryptographer and define a "novel" > Chacha20-SHA1 design, anyway that I'd feel like, send it to IETF to > standardize it as AEAD (possibly pass through CFRG as well), and few > years later when it is obsolete add it to TLS. Then implementers would > have, implement my special design and release. You could argue that I > could specify it to be exactly the same as the stream > authenticated-encryption and shortcut some of that path... Isn't that > what I'm doing? If there was commonly accepted form of AEAD that would > allow to combine a stream cipher and a MAC, that would change things, > but there isn't. There is: encrypt then MAC, using two different keys and the same nonce. This has been known for at least 20 years. > > regards, > Nikos > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Oct 3 10:09:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD0D1A07BE for ; Fri, 3 Oct 2014 10:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIAFQxCPwUMX for ; Fri, 3 Oct 2014 10:09:11 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB5D1A03F9 for ; Fri, 3 Oct 2014 10:09:11 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wn1so1194848obc.20 for ; Fri, 03 Oct 2014 10:09:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=V+1xWtGRuzZXck1Q6JvliOuFOBaGAQCsyUFe5rxPum4=; b=AyLYf0eklHJ/F+TsAItcu1gmkGJOTLEBf9kRg5Lj0rY4GDrputKygG42oL3hH2Fb1U bMdVQmHJygK5SgLY6RsXCeve6s7s1eEE2UPsHfeqaQcvSpdm8jX2y5lCAeD5clVlVgeW 0Ore/We9y8Q6r+65SwDcDxmvVzobiliAS7VR+N3dHWUJwRWMmQD8rQDS7XgVvXMDvYLp FCrOy10cXMB+vyb+pePy0gOs7QwhtlY4mQ/szKZnauE6HPZFDkJ8N4MjEwVYF1ljlr9A 0EtXpFymFUiEMtuyOeqdSswqiakVFQSLcJjC6moXZ4eEJi82gI5j5u12T6x/xcgRG5Lg W4Xw== X-Gm-Message-State: ALoCoQkZfc8T6yReWMq6DMNzz4ggW3gZO4EE0DfpRVkLZRSNqB3CgoJtRr/PzmU8iLdYz1rl2/TJ MIME-Version: 1.0 X-Received: by 10.182.181.3 with SMTP id ds3mr8356386obc.11.1412356150896; Fri, 03 Oct 2014 10:09:10 -0700 (PDT) Received: by 10.76.74.36 with HTTP; Fri, 3 Oct 2014 10:09:10 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 3 Oct 2014 10:09:10 -0700 Message-ID: From: Brian Smith To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/taXnPKPlFfSevATdQFZUsEmFM4c Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 17:09:14 -0000 On Fri, Sep 26, 2014 at 11:58 AM, Brian Smith wrote: > On Fri, Sep 26, 2014 at 12:34 AM, Bodo Moeller wrote: >>> I'm OK with that, but if this is the real reason for the MUST, then >>> it's not particularly clear. >> >> Hm, maybe so. I can add a brief note showing how the handshake would fail if >> the server acts on the SCSV in this case, but I don't think the document >> should have to explain why we require the client to omit the SCSV rather >> than having the server ignore it. (Why would you want to send it if nothing >> follows from that?) > > Here is what the draft actually says: > > However, as an exception to the above, when the client intends to > perform an abbreviated handshake to resume a previously negotiated > session and sets ClientHello.client_version to the protocol > version negotiated for that session, the client MUST NOT include > TLS_FALLBACK_SCSV in ClientHello.cipher_suites. > > So, if the client does NOT set ClientHello.client_version to the > version negotiated for that session, then the client MAY send the SCSV > in the resumption handshake. Bodo, could you please reword the above to make it clearer? e.g.: "However, as an exception to the above, when the client sets ClientHello.client_version to the protocol version negotiated for for a session that it is trying to resume, and that version is less than the ClientHello.client_version it would otherwise send if it were not attempting to resume a session, then the client MUST NOT include TLS_FALLBACK_SCSV in ClientHello.cipher_suites. For example, if the client is doing a non-secure fallback, and it is resuming a session that previously negotiated TLS 1.0, and it sets ClientHello.client_version to TLS 1.1, then TLS_FALLBACK_SCSV must be included in ClientHello.cipher_suites. However, as another example, if the client is resuming a session that previously negotiated TLS 1.0, and it sets ClientHello.client_version to TLS 1.0 to match the version number of the session, then it must not include TLS_FALLBACK_SCSV in ClientHello.cipher_suites." > Now, if the server could indicate that it supports the SCSV somehow in > its ServerHello, then the client could save that acknowledgement in Please ignore this suggestion I had about an explicit indicator. It isn't important and there are better ways of accomplishing the same effect. Cheers, Brian From nobody Fri Oct 3 14:38:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3B31A893E for ; Fri, 3 Oct 2014 14:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67X5p3C1sxmJ for ; Fri, 3 Oct 2014 14:38:03 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298D11A876E for ; Fri, 3 Oct 2014 14:38:03 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 06D911E19B; Fri, 3 Oct 2014 21:38:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1412372282; bh=hSY1UTLWqiKb1Dg/aMtcvV/iHdGKcFbnnEK70ZqcoSo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gaKO2twtrpTFYvD5ZV67FfIri8Z8BhYzowrFthziZQcKQhGLOnipl4VIQ8eSllT6d CxevaTJdwfsaC1KdFaKODDPYlGsMy8z3GW9KygxeqO8taqKrThvkYHTkss3IJfo2ix 36MfaCv88GRFukyMBplK/781GUYXaLCEmpsuit1w= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 26A2360023; Fri, 3 Oct 2014 21:37:31 +0000 (UTC) From: James Cloos To: Hubert Kario In-Reply-To: <1878200851.5790803.1412334914571.JavaMail.zimbra@redhat.com> (Hubert Kario's message of "Fri, 3 Oct 2014 07:15:14 -0400 (EDT)") References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> <1878200851.5790803.1412334914571.JavaMail.zimbra@redhat.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 03 Oct 2014 17:37:31 -0400 Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:141003:hkario@redhat.com::oqBQxSI07E1NvFRa:000000000000000000000000000000000000000000066eiF X-Hashcash: 1:28:141003:tls@ietf.org::xM6Q/r8JCC15ZE7O:00002wWpl Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4QkoHlZSqJVZACx3iz4MyVRZzDM Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 21:38:04 -0000 >>>>> "HK" == Hubert Kario writes: HK> Only about 1% of servers support only RC4 cipher, 1.5% if you're HK> using Firefox[1]. When this first came up I test a few of them. Some of the sites I tested had some sort of load balancing box listening on the main uri which redirected to the real servers. In each of the cases of that sort where the redirecting box only supported rc4, the destinations all supported a reasonably modern set of ciphers. So the problem isn't just updating typical web servers, but also dealing with what are likely low-spec closed-source fronts. It may be impossible for some of the rc4-only sites to fix that w/o replacing (probably over- priced) hardware. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Oct 3 19:46:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B828F1A8A47 for ; Fri, 3 Oct 2014 19:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y33ZhHMgd0Gn for ; Fri, 3 Oct 2014 19:46:32 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F531A8877 for ; Fri, 3 Oct 2014 19:46:31 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s942kUV2013158 for ; Fri, 3 Oct 2014 19:46:30 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0a-0016f401.pphosted.com with ESMTP id 1pt1v20nkh-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 03 Oct 2014 19:46:30 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([::1]) with mapi; Fri, 3 Oct 2014 19:46:30 -0700 From: Paul Lambert To: "tls@ietf.org" Date: Fri, 3 Oct 2014 19:46:29 -0700 Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt Thread-Index: Ac/fDkNroYyw+zfzSiSSroHPeJluhwAbN1Kw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D020DE17B869@SC-VEXCH2.marvell.com> References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> <20141003133043.GV13254@mournblade.imrryr.org> In-Reply-To: <20141003133043.GV13254@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-04_01:2014-10-03,2014-10-03,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410040031 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZYtlSH8Gxksnue5sPMZCIMetUDY Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 02:46:33 -0000 ]Before RC4 becomes MUST NOT, it needs to first become a low priority ]algorithm that is used when nothing better is available. We are over thinking the presumed interoperability concerns. There are no RFC police to enforce SHOULD versus MUST. There will not be a red-flag day when RC4 is apparently turned off=20 with a "MUST NOT" in a document from this group.=20 A 'SHOULD NOT' recommendation is readily ignored. There is no clear guidance, only a suggestion. Guidance on industry practice for such a feature is very important to help determine diligence of an implementation to follow recommended industry practice. A 'MUST NOT', could be ignored, but installations that are audited for compliance to "recommended industry practice" would be dinged. This introduces potential liability and financial risks that would encourage the removal of RC4. 'SHOULD NOT' carries no incentive for change. 'MUST NOT' provides clear guidance and incentive that will still=20 take many years to be adopted fully. Paul From nobody Fri Oct 3 20:35:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867491A8A66 for ; Fri, 3 Oct 2014 20:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXEWRWN4JT1Y for ; Fri, 3 Oct 2014 20:35:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA291A8A65 for ; Fri, 3 Oct 2014 20:35:48 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 168DD2AB2BE; Sat, 4 Oct 2014 03:35:47 +0000 (UTC) Date: Sat, 4 Oct 2014 03:35:47 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20141004033546.GG13254@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> <20141003133043.GV13254@mournblade.imrryr.org> <7BAC95F5A7E67643AAFB2C31BEE662D020DE17B869@SC-VEXCH2.marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D020DE17B869@SC-VEXCH2.marvell.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H9jPn3BO__f45y-6jgDQaYm3XNM Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 03:35:50 -0000 On Fri, Oct 03, 2014 at 07:46:29PM -0700, Paul Lambert wrote: > ]Before RC4 becomes MUST NOT, it needs to first become a low priority > ]algorithm that is used when nothing better is available. > > We are overthinking the presumed interoperability concerns. Well, I for one am not. Disabling RC4 does more harm than good with opportunistic TLS. A far better approach in that case is to de-priorioritize it. Giving some check-list enforcing clue-less auditor the ammunition to harass users into counter-productive "security" measures is not my idea of progress. > > A 'SHOULD NOT' recommendation is readily ignored. There is no > clear guidance, only a suggestion. Guidance on industry practice > for such a feature is very important to help determine diligence > of an implementation to follow recommended industry practice. And yet this is the strongest recommendation appropriate at this time. > A 'MUST NOT', could be ignored, but installations that are audited > for compliance to "recommended industry practice" would be dinged. > This introduces potential liability and financial risks that would > encourage the removal of RC4. Not all applications face the same risks, and removing RC4 will some applications *less* secure at least some of the time. > 'SHOULD NOT' carries no incentive for change. This is not the case. Both are good reason to take action. SHOULD NOT leaves room to consider when and how to respond. > 'MUST NOT' provides clear guidance and incentive that will still > take many years to be adopted fully. MUST NOT is overly broad and premature, we're moving from RC4 is best to RC4 is worst too quickly, leaving too little time to reduce the operational impact while use of RC4 is allowed to die down as auditors nag people about the "SHOULD NOT", various tutorials and guidelines are updated, articles are written, ... I think I've said as much as I must and should in this thread. Future silence will not indicate agreement with MUST NOT, rather only that there is little new to say. -- Viktor. From nobody Fri Oct 3 22:53:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CEA1A886E for ; Fri, 3 Oct 2014 22:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAkQHw2ruPmx for ; Fri, 3 Oct 2014 22:53:07 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B0571A6FF2 for ; Fri, 3 Oct 2014 22:53:07 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hi2so547296wib.8 for ; Fri, 03 Oct 2014 22:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=iBBqO4ktXV2pUwZAMxNdUf7xckPPRt+hIZzB9qt81jo=; b=oTTfo1C24GHqbrF2jc5z3EVbbvmcMwE6YBKfQ37pUFTE619UvOoJtJregEaTGPtlBc aIONAIZMxMgHCAdSq4xpfERqKd2q3CPkbzLg0Jzhoib5kPjm+JrHl4EMM3JeZhi8FYiN Z6Gu+U+zc6HZIk6nQOEmVcIWuugBr2+gMZls9vrO71WYXu9xlLCR0dj7c2jgRq36rGrf 4Kq5atUgi1pekrhj9Zn8gzxLfDhV8Ojh3ibldhWzEc+mGyYftnQ4jrBBIvZiwmrrO8V/ vT6Z13VUa3ta3PZQi6iarNHAdHUlTYz6NQkQ85JF0ebplJ9t/03GzavkkoJmanWBrxY2 wJdQ== X-Received: by 10.180.91.101 with SMTP id cd5mr3323414wib.41.1412401986253; Fri, 03 Oct 2014 22:53:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.66.225 with HTTP; Fri, 3 Oct 2014 22:52:26 -0700 (PDT) From: Ryan Carboni Date: Fri, 3 Oct 2014 22:52:26 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=14dae9cc9640abb88b05049276a0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JYnMFKyV1iv0XVLrHEwx7yaqJhs Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 05:53:09 -0000 --14dae9cc9640abb88b05049276a0 Content-Type: text/plain; charset=UTF-8 RC4 only has theoretical breaks. Most websites give you a new session cookie certainly before 2^20 visits (1048576). The recent bias only are noticeable after 2^26 (67108864) visits. --14dae9cc9640abb88b05049276a0 Content-Type: text/html; charset=UTF-8
RC4 only has theoretical breaks. Most websites give you a new session cookie certainly before 2^20 visits (1048576). The recent bias only are noticeable after 2^26 (67108864) visits.
--14dae9cc9640abb88b05049276a0-- From nobody Sat Oct 4 11:08:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AA81A0126 for ; Sat, 4 Oct 2014 11:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-PHLf3rTYdR for ; Sat, 4 Oct 2014 11:08:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 87A241A0127 for ; Sat, 4 Oct 2014 11:08:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0A326BE59 for ; Sat, 4 Oct 2014 19:08:05 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oVWRMnyWEqO for ; Sat, 4 Oct 2014 19:08:04 +0100 (IST) Received: from [10.87.48.7] (unknown [86.41.50.146]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E82CEBE20 for ; Sat, 4 Oct 2014 19:08:03 +0100 (IST) Message-ID: <54303783.2020705@cs.tcd.ie> Date: Sat, 04 Oct 2014 19:08:03 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> <20141003133043.GV13254@mournblade.imrryr.org> <7BAC95F5A7E67643AAFB2C31BEE662D020DE17B869@SC-VEXCH2.marvell.com> <20141004033546.GG13254@mournblade.imrryr.org> In-Reply-To: <20141004033546.GG13254@mournblade.imrryr.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6SPsX-7edN895WdnDcYLNTyzeKs Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 18:08:31 -0000 Hi Viktor, (No hats and without taking a position on the draft itself yet...) On 04/10/14 04:35, Viktor Dukhovni wrote: > Well, I for one am not. Disabling RC4 does more harm than good > with opportunistic TLS. Not sure I agree with that specific point. Disabling RC4 could be a configuration or code change, depending. If a code change is needed to disable RC4 then its going to be fine to use a better alg. I don't see there's a real case where there's no better alg to code up than RC4. If disabling RC4 is a config change, then in almost all cases the result should be a better alg being selected. There could I guess be cases where there's nothing better to configure, but frankly, I doubt that that's really a significant set of TLS installations. (Note that's not to say that those currently using RC4 are not significant - I'd say a lot of those could in principle change but just haven't yet.) And if anyone is going to disable RC4 and as a result end up with cleartext, then we should just get them a new foot-gun:-) So I don't think that the opportunistic security design really helps to decide SHOULD NOT vs MUST NOT for this draft. S. From nobody Sat Oct 4 11:27:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4321A0126 for ; Sat, 4 Oct 2014 11:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHgYaU5DgpLh for ; Sat, 4 Oct 2014 11:26:59 -0700 (PDT) Received: from articuno.alameth.org (articuno.alameth.org [IPv6:2600:3c01::f03c:91ff:fe70:755c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938991A0115 for ; Sat, 4 Oct 2014 11:26:59 -0700 (PDT) Received: from [192.168.147.8] (76-191-206-73.dsl.dynamic.sonic.net [76.191.206.73]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by articuno.alameth.org (Postfix) with ESMTPS id 450FE852A; Sat, 4 Oct 2014 18:32:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alameth.org; s=n01; t=1412447554; bh=IqS25kz1DtpRpoPcNBPwNJR0lpDuEjxGAkmGU3OoW6k=; h=Date:From:To:Subject:References:In-Reply-To; b=f2ebAzhCxOyFbe9j5v0G3BoR8OfMyAGpX78JBNkDtLXNCgMl7mSugpPYeatH7sMEx Os/iPieSosBIrGbGe6EVx2aj4Hl2FAK3eYvGeJ6GyhUZjRCyCLfNm6vs0S7YIgUPNW +21HNVt47Ty/TrI43vz8wssvqNOi3A7KgOVz8RWk= Message-ID: <54303BF2.2090904@alameth.org> Date: Sat, 04 Oct 2014 11:26:58 -0700 From: "Carl S. Gutekunst" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Hubert Kario , tls@ietf.org References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> <1878200851.5790803.1412334914571.JavaMail.zimbra@redhat.com> In-Reply-To: <1878200851.5790803.1412334914571.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WOzZLEDZB380vYG70zCdUNw7kpM Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 18:27:01 -0000 On 10/03/2014 04:15 AM, Hubert Kario wrote: > This is not the case. > > Only about 1% of servers support only RC4 cipher, 1.5% if you're > using Firefox[1]. > > On the other hand, over 21% of servers will negotiate a RC4 cipher > in case you're using Firefox (and nearly 18% if you're using > OpenSSL-like supported cipher list). Note that in the SMTP world, use of RC4 (and a bias towards RC4) is more prevalent than on web servers. This is in large measure because Microsoft Exchange Server 2003 shipped with only RC4 and 3DES, and the 3DES implementation crashed somewhere around the MAIL FROM dialog. I still regularly run into these old, unpatched servers. I tell them to install AES support, but they usually ignore me, abandon my product, and switch to one that "works" -- that is, it uses TLS v1 and RC4. From nobody Sun Oct 5 16:19:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FED1A0118 for ; Sun, 5 Oct 2014 16:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaEIePqBC4zf for ; Sun, 5 Oct 2014 16:19:31 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC8F1A0101 for ; Sun, 5 Oct 2014 16:19:31 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so5229035wgh.12 for ; Sun, 05 Oct 2014 16:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=RGB+fGVH1V8UVmyAgxqPccwfTnVMrmZy7Pt4xFgmId0=; b=qoAfhzf2eYoiAiExiaLL3oE8/IvyktDnziD4NEDM2tLpx/C6nnkW1XkCVJ6Ew5PS/c ZkNXmjUw8ym2puyEFrRd5ZeehAAovaKDIRmqhqvKjfT1mOqMjiWVYcuSKZ/8ZDhZiSEu ryd+LtK7SFRpi96b5wY9UGlmEs8fd+mzftRFVLKy1+FBUTy7c1YA9WvOCuEzT/1R8HKr 8usmfZGrdBd0NKpH7c9QoKhfoy6EjDqsOup12L/hf2qDdf0FrHPhiXUdqRlSCU84u0gd I+77CTn47ntte11zxUAQ94p25QTlc3DNykGYXhj/2yPJjMIen7lwh3dqvq6nmaa+uHNt BOsg== X-Received: by 10.194.88.99 with SMTP id bf3mr25387800wjb.16.1412551170141; Sun, 05 Oct 2014 16:19:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.66.225 with HTTP; Sun, 5 Oct 2014 16:18:50 -0700 (PDT) From: Ryan Carboni Date: Sun, 5 Oct 2014 16:18:50 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e0102ffe8b934eb0504b532fe Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bI7o45NnUXYDdFsjhNPMV4tt_U0 Subject: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 23:19:37 -0000 --089e0102ffe8b934eb0504b532fe Content-Type: text/plain; charset=UTF-8 https://en.wikipedia.org/wiki/Speck_%28cipher%29 --089e0102ffe8b934eb0504b532fe Content-Type: text/html; charset=UTF-8 --089e0102ffe8b934eb0504b532fe-- From nobody Sun Oct 5 16:54:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161CB1A0137 for ; Sun, 5 Oct 2014 16:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMYMRwooZyVZ for ; Sun, 5 Oct 2014 16:54:01 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 563AC1A0120 for ; Sun, 5 Oct 2014 16:54:01 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 19so1546523ykq.17 for ; Sun, 05 Oct 2014 16:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SrsRzJfSBfl32SNAWux6cWuSBTibBhGLTGBFKpCq1EA=; b=PXdo7HTQ8kGCXOnPakK+BZ0a5B+QZUvgUqGMcyxn6lHTeoRnn+MhFNtf7b0LffAfs3 qabY4s1JlmF/RKfSWQH1xWFCN/OoOlPXxip1MQ2U6an2ea5oTBUKW7MWULaDknBWBiWZ ByLLUhqW0TyK/+jwI6PCuu1D65iz2+Q3945YwUikAeSjnjJEQTEaEHTChFbRt7OcY1/c NyhWwL28S53D5O8hbjqwrmj5HyxfDYPd/QLgWwA0OCXJBZhGDBVX3ZTSMAqluwEkKYMp l0iUW16g+XvASKT7HmWR42h2h4yi4rOGxfWIu6tURabHAmKKDEqRbBBNIjp8T+/O5dKu 6MWQ== MIME-Version: 1.0 X-Received: by 10.236.88.226 with SMTP id a62mr32861454yhf.64.1412553240638; Sun, 05 Oct 2014 16:54:00 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Sun, 5 Oct 2014 16:54:00 -0700 (PDT) In-Reply-To: References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> <1878200851.5790803.1412334914571.JavaMail.zimbra@redhat.com> Date: Sun, 5 Oct 2014 16:54:00 -0700 Message-ID: From: Watson Ladd To: James Cloos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pf5Z9S6_V4lERLKGJkOodtmG_hc Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 23:54:06 -0000 On Fri, Oct 3, 2014 at 2:37 PM, James Cloos wrote: >>>>>> "HK" == Hubert Kario writes: > > HK> Only about 1% of servers support only RC4 cipher, 1.5% if you're > HK> using Firefox[1]. > > When this first came up I test a few of them. Some of the sites I > tested had some sort of load balancing box listening on the main uri > which redirected to the real servers. In each of the cases of that > sort where the redirecting box only supported rc4, the destinations > all supported a reasonably modern set of ciphers. > > So the problem isn't just updating typical web servers, but also dealing > with what are likely low-spec closed-source fronts. It may be impossible > for some of the rc4-only sites to fix that w/o replacing (probably over- > priced) hardware. Then that's what they are going to have to do at some point. SHOULD pushes that point off with no reason. > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Oct 5 18:38:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DFC1A0282 for ; Sun, 5 Oct 2014 18:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9WjgdS-ll_c for ; Sun, 5 Oct 2014 18:38:14 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id B287F1A0275 for ; Sun, 5 Oct 2014 18:38:14 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DB93E1658CF; Mon, 6 Oct 2014 01:38:13 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id D076F165896; Mon, 6 Oct 2014 01:38:13 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub2.dfw01.corp.akamai.com [172.27.25.76]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id CD75E98055; Mon, 6 Oct 2014 01:38:13 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub2.dfw01.corp.akamai.com ([172.27.25.76]) with mapi; Sun, 5 Oct 2014 20:38:13 -0500 From: "Salz, Rich" To: Ryan Carboni , "tls@ietf.org" Date: Sun, 5 Oct 2014 20:38:12 -0500 Thread-Topic: [TLS] Include Speck block cipher? Thread-Index: Ac/g8tg7UOq+zthZSj2JqIcmkOKodQAEyP+w Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F8547@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mdZSQpNLYolU0ptEN1cLh1OfazE Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 01:38:17 -0000 WW914oCZZCBoYXZlIHRvIG1ha2UgYW4gQUVBRCBjb25zdHJ1Y3Qgb3V0IG9mIGl0LiBUTFMgMS4z IGlzIG9ubHkgZG9pbmcgQUVBRC1zdHlsZSBjaXBoZXJzLg0KDQotLSAgDQpQcmluY2lwYWwgU2Vj dXJpdHkgRW5naW5lZXIsIEFrYW1haSBUZWNobm9sb2dpZXMNCklNOiByc2FsekBqYWJiZXIubWUg VHdpdHRlcjogUmljaFNhbHoNCg0KDQo= From nobody Sun Oct 5 19:22:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6024A1A02F9 for ; Sun, 5 Oct 2014 19:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou6QbxXbwAvD for ; Sun, 5 Oct 2014 19:22:22 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A771A00F9 for ; Sun, 5 Oct 2014 19:22:21 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 10so1633819ykt.28 for ; Sun, 05 Oct 2014 19:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=X6sgCm4i8zoziS+lPSga4Za8Y45ucffD1YchZqMCvC0=; b=I8XbnhQll6d3kUEuJD9kx4AO9NQxxpCwcsVt/voRApcilbA6n1t4jfUm0WEPYb0eKx WmbnKkhnUMb3ZqXAXM7+bB84vXX/TjFjVkckhxKEnX9b8Mf9zy3Vk+xXzzPGExNKemDR NEfjIUsLTPT06L2rDLTZWxZL6CJ7jLKIP+iRaORmKUohjMUaa3HU7RO5xx0ar7uOtVDD WZdCbBvMKq25JszwqWjW+TPpjUD3Kx7vjJMS6w/ZJP3UHnQH26oFiXkwJuYRirKydhRs 3XqGV+m0DVFHKluxH/cSb3EZJ0byCXOYY2nIRXzJH/MsirCsq9AF6VmoKmXqVzne9s8H CATA== MIME-Version: 1.0 X-Received: by 10.236.133.11 with SMTP id p11mr32362056yhi.51.1412562141279; Sun, 05 Oct 2014 19:22:21 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Sun, 5 Oct 2014 19:22:21 -0700 (PDT) Date: Sun, 5 Oct 2014 19:22:21 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_ZsUWutc_suX-h40oSobtvQcZuk Subject: [TLS] Products supporting TLS 1.0 & some other high-level questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 02:22:23 -0000 Is the prefered path -Adoption of TLS 1.3 -Adoption of TLS 1.2+session_hash fix -Indefinite support for TLS 1.0 plus multiple, not widely deployed fixes. The answer to this question affects how complex we force minimal implementations of TLS 1.3 to be. The other high level question is tying to X509. The current draft requires the server and client to be identified by X509 certificates. While this repeats what previous versions have done, X509 is not a perfect match for all uses. Sincerely, Watson Ladd From nobody Sun Oct 5 19:34:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB11F1A0334 for ; Sun, 5 Oct 2014 19:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esrJscENrvO1 for ; Sun, 5 Oct 2014 19:33:58 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D8A1A0331 for ; Sun, 5 Oct 2014 19:33:58 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x13so5369411wgg.6 for ; Sun, 05 Oct 2014 19:33:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0+UxvcZodQYf1jNkjjgBIoxAPL2XIXdRZ8h/WQ9TbXI=; b=F4/3ycLZQJEHl+nKQd6XgM9nJU4d6UK+scMVo1WZMNddc5r6SAq4okNi0Nt3ezk0Zh XtFMiyY+trd+diS+yu21zpBOGGfKxpNi4fM19KegylQpDO1ASx8IQuOwTcqZ+mwtjcqz ji0npAqBOM+GPTVs6IAi9JugQVolZYBu9bDXX/4Pn2GHuyOMUOFyZkA1RJMcAA+se0EO FuHCVDfiQe3zz7dh7HVfId6Cq2XmcNRROXY76F6qA++h6gsthvKyOqKJYHPgOFH1FXIs Q2xMWsBO8QsLEpAtwQrUADRUc1j4EJNR1GD+JRgPTTd9gZf5xJT5O8zKaAiGqm3THVTP izCA== X-Gm-Message-State: ALoCoQl4SGbhPrSkJS5AdOlHjln6St5ZwPxbkfhXYaRLXOPVoYWR3HgXHz0y9qmNkgEvTtEyzd2M X-Received: by 10.180.106.104 with SMTP id gt8mr7618658wib.13.1412562837092; Sun, 05 Oct 2014 19:33:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.130.130 with HTTP; Sun, 5 Oct 2014 19:33:17 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 5 Oct 2014 19:33:17 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d04428ee220cb0b0504b7ea67 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wfkP5KTfuM9TJxAFi_ZGVLsQLNo Cc: "tls@ietf.org" Subject: Re: [TLS] Products supporting TLS 1.0 & some other high-level questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 02:34:00 -0000 --f46d04428ee220cb0b0504b7ea67 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 5, 2014 at 7:22 PM, Watson Ladd wrote: > Is the prefered path > -Adoption of TLS 1.3 > -Adoption of TLS 1.2+session_hash fix > -Indefinite support for TLS 1.0 plus multiple, not widely deployed fixes. > As a practical matter, we're likely to get at least the first two and probably all three. The other high level question is tying to X509. The current draft > requires the server and client to be identified by X509 certificates. > While this repeats what previous versions have done, X509 is not a > perfect match for all uses. As you probably know, there are TLS documents which allow for both PGP (RFC 6091) and for raw keys (RFC 7250). I haven't studied the matter, but I expect that they are compatible or can be made compatible with TLS 1.3. For obvious reasons, we'll likely need to retain X.509, but we can certainly reference/update these documents or merge them in if people really want to. -Ekr --f46d04428ee220cb0b0504b7ea67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Oct 5, 2014 at 7:22 PM, Watson Ladd <watsonbladd@gmail.com>= wrote:
Is the prefered path
-Adoption of TLS 1.3
-Adoption of TLS 1.2+session_hash fix
-Indefinite support for TLS 1.0 plus multiple, not widely deployed fixes.

As a practical matter, we're likely = to get at least the first two and
probably all three.
<= br>

The other high level question is tying to X509. The current draft
requires the server and client to be identified by X509 certificates.
While this repeats what previous versions have done, X509 is not a
perfect match for all uses.

As you probably= know, there are TLS documents which allow for both
PGP (RFC = 6091) and for raw keys (RFC 7250). I haven't studied the
matt= er, but I expect that they are compatible or can be made compatible
with TLS 1.3. For obvious reasons, we'll likely need to retain X.509= ,
but we can certainly reference/update these documents or merge = them
in if people really want to.

-Ekr




=C2=A0=
--f46d04428ee220cb0b0504b7ea67-- From nobody Sun Oct 5 19:36:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B131A0334 for ; Sun, 5 Oct 2014 19:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk5y54T0waFO for ; Sun, 5 Oct 2014 19:36:32 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6461A0331 for ; Sun, 5 Oct 2014 19:36:32 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B8F31284F6; Mon, 6 Oct 2014 02:36:31 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id A578C284F5; Mon, 6 Oct 2014 02:36:31 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub7.dfw01.corp.akamai.com [172.27.25.73]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 8109C202A; Mon, 6 Oct 2014 02:36:31 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub7.dfw01.corp.akamai.com ([172.27.25.73]) with mapi; Sun, 5 Oct 2014 21:36:30 -0500 From: "Salz, Rich" To: Eric Rescorla , Watson Ladd Date: Sun, 5 Oct 2014 21:36:30 -0500 Thread-Topic: [TLS] Products supporting TLS 1.0 & some other high-level questions Thread-Index: Ac/hDf8MAVguCvlvS8q/oNZBPyrTDwAABfUw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F8550@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Y-iNvrYVN9tRFrE5eGpgYSq7vUY Cc: "tls@ietf.org" Subject: Re: [TLS] Products supporting TLS 1.0 & some other high-level questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 02:36:35 -0000 SSB0aGluayBodHRwLzIsIHdoaWNoIG1hbnkgcGVvcGxlIHdhbnQgYmVjYXVzZSBvZiBwZXJjZWl2 ZWQgZWZmaWNpZW5jaWVzLCB3aWxsIGJlIGEgbWFqb3IgZmFjdG9yIGZvciBwdWxsaW5nIFRMUyAx LjMgZXNwZWNpYWxseSBpZiB0aGUgbGF0dGVyIGFkb3B0cyBDaGFDaGEvUG9seSBhbmQvb3IgWDI1 NTE5Lg0KDQpJZiBJIHdlcmUgYSBjb25zcGlyYWN5IGZhbiwgSSdkIGJlIHdvcnJpZWQgYWJvdXQg dGhlIGNsb3NlIHByb2Zlc3Npb25hbCByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgYXV0aG9ycyBv ZiB0aGUgVExTICAxLjMgYW5kIEhUVFAvMiBSRkMncyA6KQ0KDQoJL3IkDQoNCg== From nobody Sun Oct 5 22:28:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9C91A1B33 for ; Sun, 5 Oct 2014 22:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_TvMe5SwHJV for ; Sun, 5 Oct 2014 22:28:23 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C1E1A1AFE for ; Sun, 5 Oct 2014 22:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1412573303; x=1444109303; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=fSM7ZOAreuajCapoW0S0w/2aRjX5EWJ1dBFVgQjHkfE=; b=manSLZIuzW0srtin0GCnCBRWLAzEPY5RWM17yMrynUD8UPvU28xm+VC1 n2TbsLptC6suAdOkjf2cEQd9GhAlTTTfplEqb4aq+D1laNEg2kA8rQG6v bDgfhaC3ypn5hMtQdE10jCpso8f0oowcFYZaXI2wkBiI2r1TvjaFg+h2W U=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="280689009" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 06 Oct 2014 18:28:19 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Mon, 6 Oct 2014 18:28:19 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Products supporting TLS 1.0 & some other high-level questions Thread-Index: Ac/hJlWqA3GJ5xtDTm6FwYAtMmIi/w== Date: Mon, 6 Oct 2014 05:28:17 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9C228B@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QTA8c0hioQwNCpqlye5pqOigXZ0 Subject: Re: [TLS] Products supporting TLS 1.0 & some other high-level questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 05:28:26 -0000 Eric Rescorla writes:=0A= >On Sun, Oct 5, 2014 at 7:22 PM, Watson Ladd wrote:= =0A= >> Is the prefered path=0A= >> -Adoption of TLS 1.3=0A= >> -Adoption of TLS 1.2+session_hash fix=0A= >> -Indefinite support for TLS 1.0 plus multiple, not widely deployed fixes= .=0A= >=0A= >As a practical matter, we're likely to get at least the first two and=0A= >probably all three.=0A= =0A= You forgot one important word: eventually. TLS 1.1 + add-ons we've got now= .=0A= TLS 1.2 + session hash fix is still a work in progress after six years (eig= ht=0A= if you take it back to the draft versions, which were mostly implementable= =0A= even then). TLS 1.3, which should really be called TLS 2.0 because there a= re=0A= so many fundamental changes, could take a decade or more (based on the 1.2= =0A= timeline) to see widespread deployment. I'm sure Google will rush it out i= n=0A= Chrome and bundle it with HTTP 2.0 (at least they're calling that 2.0 rathe= r=0A= than pretending it's still a 1.x version) because it's of benefit to them, = but=0A= for non-browser use you're going to see a long tail worthy of the Midgard= =0A= Serpent. So I think you'll end up with a split, "TLS for browsers" (1.3=0A= a.k.a. 2.0) and "TLS for everyone else" (1.1 or maybe 1.2).=0A= =0A= Peter.= From nobody Sun Oct 5 22:33:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B271A1B34 for ; Sun, 5 Oct 2014 22:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.274 X-Spam-Level: X-Spam-Status: No, score=-1.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zEgoudnl8vs for ; Sun, 5 Oct 2014 22:33:34 -0700 (PDT) Received: from articuno.alameth.org (articuno.alameth.org [IPv6:2600:3c01::f03c:91ff:fe70:755c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E97E1A1B33 for ; Sun, 5 Oct 2014 22:33:34 -0700 (PDT) Received: from [192.168.147.8] (76-191-206-73.dsl.dynamic.sonic.net [76.191.206.73]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by articuno.alameth.org (Postfix) with ESMTPS id 561868536; Mon, 6 Oct 2014 05:39:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alameth.org; s=n01; t=1412573951; bh=MpGAIqsGm8a/mG0CMTS0VEgTrKkhfZJo9ahViiirahI=; h=Date:From:To:Subject:References:In-Reply-To; b=QQFjKr5Cn098oL98Jg4vQXFzD2EZq+0k6i8tcx6hCBTU2QWlgXNyLo0OIgXVZ5l2i HN91UT+eWZGHV46dJ62drpx080qNFp3VvAX/mpJGVxWAgexXB7qLzBlTjJDQvwUYH9 HKH00wc3kOEKO5Dis1M/PjK4ExDQxWStprhD40+g= Message-ID: <543229AD.7070401@alameth.org> Date: Sun, 05 Oct 2014 22:33:33 -0700 From: "Carl S. Gutekunst" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C739B9C228B@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9C228B@uxcn10-tdc05.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jjkIaUQ9CP5ArFHoVf08zRFMtl4 Subject: Re: [TLS] Products supporting TLS 1.0 & some other high-level questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 05:33:35 -0000 On 10/05/2014 10:28 PM, Peter Gutmann wrote: > Eric Rescorla writes: >> On Sun, Oct 5, 2014 at 7:22 PM, Watson Ladd wrote: >>> Is the prefered path >>> -Adoption of TLS 1.3 >>> -Adoption of TLS 1.2+session_hash fix >>> -Indefinite support for TLS 1.0 plus multiple, not widely deployed fixes. >> As a practical matter, we're likely to get at least the first two and >> probably all three. > You forgot one important word: eventually. TLS 1.1 + add-ons we've got now. > TLS 1.2 + session hash fix is still a work in progress after six years (eight > if you take it back to the draft versions, which were mostly implementable > even then). TLS 1.3, which should really be called TLS 2.0 because there are > so many fundamental changes, could take a decade or more.... And -- I hate repeating myself, but it seemed germane to this thread -- I'm still regularly having to deal with SBS 2003 servers whose only "strong" ciphers are RC4 and a non-functional implementation of 3DES. From nobody Mon Oct 6 06:16:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374731A6F24; Mon, 6 Oct 2014 06:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykV1CpoAsd4m; Mon, 6 Oct 2014 06:16:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F29E1A6F29; Mon, 6 Oct 2014 06:16:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141006131625.5451.13842.idtracker@ietfa.amsl.com> Date: Mon, 06 Oct 2014 06:16:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xziGo1kmwVKPbxHmSCaXDTvxK1o Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-session-hash-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:16:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension Authors : Karthikeyan Bhargavan Antoine Delignat-Lavaud Alfredo Pironti Adam Langley Marsh Ray Filename : draft-ietf-tls-session-hash-02.txt Pages : 9 Date : 2014-10-06 Abstract: The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the client and server identities. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-session-hash-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-session-hash-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 6 06:27:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937961A6F57 for ; Mon, 6 Oct 2014 06:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjQNr-ns5xw2 for ; Mon, 6 Oct 2014 06:27:36 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0561A6F42 for ; Mon, 6 Oct 2014 06:27:19 -0700 (PDT) Received: by mail-oi0-f48.google.com with SMTP id g201so3540249oib.21 for ; Mon, 06 Oct 2014 06:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Wx8IgQgKSGBj4otaciMQSz9uD5ydp3PbvkBUGCUnw1o=; b=dPbkj01vz2I5hNH3v/F+UAMWbabRYi1ymWo15gd2RlyT9ueJQIbaRnHr/9Cat9guMi gzdfsBgZGe3ZhYWJCpeEJdAgP5CU7RD0MyvA6pcMJ7CPzzbtgicSGQAQk8/NxqsHnRyG zbxpWNBM6+746dM9mBaI9j6YK/NPw9Fk3oOQ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Wx8IgQgKSGBj4otaciMQSz9uD5ydp3PbvkBUGCUnw1o=; b=BXljEiAssFbvc6N5ECFK4f2n4YuUtyJGr2h1J6Ua3kfmzHrxeMdfulWHgpBor4N+TG cC4jp9qEXjymEKfHJb6g+3erldjRJzzBxTISNofhDwAMKCE72mdBO16dnR3wFoq1Tjed T77RhcBAhvR7pkggEnJhQ8DuOfk66jXU4XXhurk3jQA/9aQ/szcAPlZ9iMMLwZeMSd00 T7W2VuJsDSqN35GXJc0T6a14bNQpRcw6kHAn5UN0ku0owzxlx1tf740FCfwtmwz6U10V W1gBKJddIanWD3xa0hLsFQ8+D1816P3/nQSzhK8FI/SrrufIszDIwAM2SQjzS8VnhlQU c1nw== X-Gm-Message-State: ALoCoQnCcrjmkeqX7BP0eIkbhjnh0XpsFO6sYD8Ftb73BKSS4tPaelDNwRKbsuIPYGQAd263yFy/ MIME-Version: 1.0 X-Received: by 10.60.177.231 with SMTP id ct7mr27313735oec.8.1412602038425; Mon, 06 Oct 2014 06:27:18 -0700 (PDT) Received: by 10.76.90.168 with HTTP; Mon, 6 Oct 2014 06:27:18 -0700 (PDT) X-Originating-IP: [2001:660:3013:3:4ded:8ffd:6cca:1578] In-Reply-To: <20141006131625.5451.13842.idtracker@ietfa.amsl.com> References: <20141006131625.5451.13842.idtracker@ietfa.amsl.com> Date: Mon, 6 Oct 2014 15:27:18 +0200 Message-ID: From: Alfredo Pironti To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e01182fc4b5b2c50504c10a73 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cthyTwPiW9BLtkPc_psqYKvJ85Y Subject: Re: [TLS] I-D Action: draft-ietf-tls-session-hash-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:27:40 -0000 --089e01182fc4b5b2c50504c10a73 Content-Type: text/plain; charset=UTF-8 Dear list, I've updated the extended master secret draft according to your feedback. In particular, I've clarified - computation of the extended master secret for the TLS and SSL 3.0 protocols - differences between the extended master secret computation and the original one The draft now uses 23 as the IANA assigned extension number. We've set up a test server, available at mitls.org:2443. The running implementation is miTLS, with experimental support for the extended master secret extension. Best, Alfredo On Mon, Oct 6, 2014 at 3:16 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security Working Group > of the IETF. > > Title : Transport Layer Security (TLS) Session Hash and > Extended Master Secret Extension > Authors : Karthikeyan Bhargavan > Antoine Delignat-Lavaud > Alfredo Pironti > Adam Langley > Marsh Ray > Filename : draft-ietf-tls-session-hash-02.txt > Pages : 9 > Date : 2014-10-06 > > Abstract: > The Transport Layer Security (TLS) master secret is not > cryptographically bound to important session parameters such as the > client and server identities. Consequently, it is possible for an > active attacker to set up two sessions, one with a client and another > with a server, such that the master secrets on the two sessions are > the same. Thereafter, any mechanism that relies on the master secret > for authentication, including session resumption, becomes vulnerable > to a man-in-the-middle attack, where the attacker can simply forward > messages back and forth between the client and server. This > specification defines a TLS extension that contextually binds the > master secret to a log of the full handshake that computes it, thus > preventing such attacks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-session-hash-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-session-hash-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e01182fc4b5b2c50504c10a73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear list,

I've updated the extended master secret draft according to your feedba= ck. In particular, I've clarified
- computation of the extende= d master secret for the TLS and SSL 3.0 protocols
- differences be= tween the extended master secret computation and the original one
= The draft now uses 23 as the IANA assigned extension number.

W= e've set up a test server, available at mitls.org:2443. The running implementation is miTLS, with experiment= al support for the extended master secret extension.

Best,
=
Alfredo

On Mon, Oct 6, 2014 at 3:16 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Transport Layer Security Working Gro= up of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Transport Layer Security (TLS) Session Hash and Extended Master Secret Ext= ension
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Kart= hikeyan Bhargavan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Antoine Delignat-Lavaud
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Alfredo Pironti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Adam Langley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Marsh Ray
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tls-session-hash-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-10-06

Abstract:
=C2=A0 =C2=A0The Transport Layer Security (TLS) master secret is not
=C2=A0 =C2=A0cryptographically bound to important session parameters such a= s the
=C2=A0 =C2=A0client and server identities.=C2=A0 Consequently, it is possib= le for an
=C2=A0 =C2=A0active attacker to set up two sessions, one with a client and = another
=C2=A0 =C2=A0with a server, such that the master secrets on the two session= s are
=C2=A0 =C2=A0the same.=C2=A0 Thereafter, any mechanism that relies on the m= aster secret
=C2=A0 =C2=A0for authentication, including session resumption, becomes vuln= erable
=C2=A0 =C2=A0to a man-in-the-middle attack, where the attacker can simply f= orward
=C2=A0 =C2=A0messages back and forth between the client and server.=C2=A0 T= his
=C2=A0 =C2=A0specification defines a TLS extension that contextually binds = the
=C2=A0 =C2=A0master secret to a log of the full handshake that computes it,= thus
=C2=A0 =C2=A0preventing such attacks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-session-ha= sh/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-session-hash-02<= br>
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-sess= ion-hash-02


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--089e01182fc4b5b2c50504c10a73-- From nobody Mon Oct 6 06:34:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32E81A6F49 for ; Mon, 6 Oct 2014 06:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWDsFzoONnpv for ; Mon, 6 Oct 2014 06:34:36 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16531A6F57 for ; Mon, 6 Oct 2014 06:34:31 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 984521E111; Mon, 6 Oct 2014 13:34:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1412602470; bh=gz92zSAldDY4H0HocK3QZBwzUIM3b9GNHNoquY3pJPA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DK9Iuy0M5Ve9vN1HoHrmX39PggP/kB7/rYY+ceN2zfd2ErJMS11dyjQ8UxlK6jWo9 7G2tll3jqMSxw1PzoCo3woZKuJL1BGDnd3yXSpQpS2sGmZqdyQMlwgckYQ7iYyzADX Il0YcFaEL2CbN66VoA2GAsv3ilrJtmSqGAQdiW0c= Received: by carbon.jhcloos.org (Postfix, from userid 500) id DC0EB60024; Mon, 6 Oct 2014 13:31:12 +0000 (UTC) From: James Cloos To: Watson Ladd In-Reply-To: (Watson Ladd's message of "Sun, 5 Oct 2014 16:54:00 -0700") References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> <1878200851.5790803.1412334914571.JavaMail.zimbra@redhat.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 06 Oct 2014 09:31:12 -0400 Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:141006:watsonbladd@gmail.com::aN4jVJGWOo+motht:000000000000000000000000000000000000000TLTDm X-Hashcash: 1:28:141006:hkario@redhat.com::kr2aJOK/2CzwXarR:0000000000000000000000000000000000000000000fJiTj X-Hashcash: 1:28:141006:tls@ietf.org::ORpJHETnxnsNYhET:00002vBcP Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ikmCrMWqGF1wbW-9vYaXBCs3JNE Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:34:37 -0000 >>>>> "WL" == Watson Ladd writes: >> So the problem isn't just updating typical web servers, but also dealing >> with what are likely low-spec closed-source fronts. It may be impossible >> for some of the rc4-only sites to fix that w/o replacing (probably over- >> priced) hardware. WL> Then that's what they are going to have to do at some point. SHOULD WL> pushes that point off with no reason. TO be clear, I wasn't arguing against retiring rc4, just noting that sites exist which are unlikely to do so in the short to medium term. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Oct 6 10:13:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740561A8549 for ; Mon, 6 Oct 2014 10:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WISTzJcxoTJN for ; Mon, 6 Oct 2014 10:13:50 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75EE1A8712 for ; Mon, 6 Oct 2014 10:13:43 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 17:13:42 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1044.008; Mon, 6 Oct 2014 17:13:42 +0000 From: Andrei Popov To: James Cloos , Watson Ladd Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt Thread-Index: AQHP3vtVNMA/cCYK50uAePFfMxwCEpwe5rNWgANKmgCAAOVSioAAOvlg Date: Mon, 6 Oct 2014 17:13:42 +0000 Message-ID: References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> <1878200851.5790803.1412334914571.JavaMail.zimbra@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB419; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03569407CC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(189002)(377454003)(2656002)(76576001)(20776003)(40100001)(87936001)(85852003)(21056001)(86612001)(95666004)(106116001)(64706001)(33646002)(85306004)(10300001)(107046002)(93886004)(4396001)(19580405001)(19580395003)(86362001)(76482002)(99396003)(15975445006)(120916001)(80022003)(74316001)(97736003)(101416001)(54356999)(76176999)(46102003)(106356001)(105586002)(99286002)(230783001)(50986999)(108616004)(122556001)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cQxe_G-wK4BngHJ3J9lb2jYKmRw Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 17:13:53 -0000 > TO be clear, I wasn't arguing against retiring rc4, just noting that site= s exist which are unlikely to do so in the short to medium term. Absolutely, but I think most new RFCs take a while to be implemented and de= ployed. RC4 is not going to become any more secure in the short, medium, or= long term, so I believe prohibiting-RC4 will remain relevant for as long a= s TLS versions <1.3 are in use. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of James Cloos Sent: Monday, October 6, 2014 6:31 AM To: Watson Ladd Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt >>>>> "WL" =3D=3D Watson Ladd writes: >> So the problem isn't just updating typical web servers, but also=20 >> dealing with what are likely low-spec closed-source fronts. It may=20 >> be impossible for some of the rc4-only sites to fix that w/o=20 >> replacing (probably over- >> priced) hardware. WL> Then that's what they are going to have to do at some point. SHOULD=20 WL> pushes that point off with no reason. TO be clear, I wasn't arguing against retiring rc4, just noting that sites = exist which are unlikely to do so in the short to medium term. -JimC --=20 James Cloos OpenPGP: 0x997A9F17ED7DAEA6 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Oct 6 12:59:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536021A8970 for ; Mon, 6 Oct 2014 12:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQXMI1Gey5RQ for ; Mon, 6 Oct 2014 12:59:00 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FB81A8983 for ; Mon, 6 Oct 2014 12:58:47 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 4F7AB7A276; Mon, 6 Oct 2014 21:58:45 +0200 (CEST) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 037FE42E14; Mon, 6 Oct 2014 21:58:45 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id ED7D61AEB1; Mon, 6 Oct 2014 21:58:44 +0200 (CEST) In-Reply-To: <1878200851.5790803.1412334914571.JavaMail.zimbra@redhat.com> To: Hubert Kario Date: Mon, 6 Oct 2014 21:58:44 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141006195844.ED7D61AEB1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1gUPylsqxXHBwCsU-KB3RCbs_sw Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 19:59:07 -0000 Hubert Kario wrote: > > Only about 1% of servers support only RC4 cipher, 1.5% if you're > using Firefox[1]. > > On the other hand, over 21% of servers will negotiate a RC4 cipher > in case you're using Firefox (and nearly 18% if you're using > OpenSSL-like supported cipher list). > > So by dropping RC4 from your first ClientHello (in case you do use > fallback) may as well cut your RC4 usage by over 20%! We're talking past each other here. I'm perfectly OK with the MUST NOT for the __client__ (!!), and I will not mind the slightest if (Browser or other) TLS clients that implement the awkward application-level reconnect fallback logic for TLS handshake failures start "punishing" the remaining RC4-only servers with reconnect fallbacks. My issue is with the IMHO bogus "MUST NOT" for servers. Servers have no control over the client behaviour, and the current proposal calls for an unconditional hard failure (equals to "come back in clear text") rather than interoperating with an RC4-based TLS cipher suites with installed base clients. Based on what we currently know about the weaknesses of RC4, unconditionally turning down clients will be ridiculously stupid in most situations, because for the vast number of scenarios, the weakness of the TLS RC4 cipher suites is not a threat. -Martin From nobody Mon Oct 6 13:12:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A151A8955 for ; Mon, 6 Oct 2014 13:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akjsgZ35PaT8 for ; Mon, 6 Oct 2014 13:12:32 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708041A8953 for ; Mon, 6 Oct 2014 13:12:32 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so7508548wgh.0 for ; Mon, 06 Oct 2014 13:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jLT4bb6DQ7GIRHVOpBJz96OpuIlojXgm1XZXtmNjsks=; b=GC2Gov/mBRdjCwAsHJ+JCCfM2aMmAr/aqZbF1kynsJHrhtLo8huzHqwgeoQlvIugLv l1kEmji0LkLFo7ziZ5ZXSeosheyQYcTtyj6S6oBdmeiLf8kXlwpTzTQVPV7D/R0C9dS5 s3Ua8raDa+EEk9nkIVyLDkGPWX/LVYivUjea+o5j1dWgUG+en0upV6ZxH91LS2DnH187 zYSnJ1ncUGs3QKkbZYx0Be9efiSyRis5XlktCOpiBbOKIsI8K4aBhi5AA+pZuT3RGmdl jb2JHJfgmPp420TEMEaKWUZgHiKa6+7fgIFoohjpYe84XvaisbECTJSo0m0TsaU2y2AV kuSw== X-Received: by 10.194.58.13 with SMTP id m13mr5409944wjq.134.1412626351051; Mon, 06 Oct 2014 13:12:31 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-54-144.inter.net.il. [84.228.54.144]) by mx.google.com with ESMTPSA id ny6sm12347456wic.22.2014.10.06.13.12.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Oct 2014 13:12:30 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <20141006195844.ED7D61AEB1@ld9781.wdf.sap.corp> Date: Mon, 6 Oct 2014 23:12:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <59776220-309B-4E6B-870D-66F8A0F4D7B5@gmail.com> References: <20141006195844.ED7D61AEB1@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/j7pErFoQAGGi3rAsvZYlHI2UBpw Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 20:12:34 -0000 On Oct 6, 2014, at 10:58 PM, Martin Rex wrote: >=20 >=20 > Based on what we currently know about the weaknesses of RC4, > unconditionally turning down clients will be ridiculously stupid > in most situations, because for the vast number of scenarios, > the weakness of the TLS RC4 cipher suites is not a threat. Hi, Martin. Both your implementation and mine have to deal with customers that run 4 = or 5 year old software, and refuse to patch their systems. We know this = is true, because TLS has a padding extension only because customers = refuse to patch their systems. So if the version that I am working on now is going to come out in 2015, = some customers are going to run it in 2020. It should not include things = that are likely to be ridiculous in 2020. So avoiding RC4 now is good. = Avoiding SHA-1 in signatures is another good idea. Google can patch = everyone=92s Chrome in days. We are not so lucky. So I think it should be MUST NOT for RC4. If some things can=92t yet = afford to comply with the new RFC, so be it. They=92ll get there = eventually. Yoav From nobody Mon Oct 6 13:17:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46F21A8961 for ; Mon, 6 Oct 2014 13:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEi4uIoIuM4z for ; Mon, 6 Oct 2014 13:17:25 -0700 (PDT) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443101A8965 for ; Mon, 6 Oct 2014 13:17:24 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s96KHNPN009260; Mon, 6 Oct 2014 16:17:23 -0400 Date: Mon, 6 Oct 2014 16:17:22 -0400 (EDT) From: Hubert Kario To: mrex@sap.com Message-ID: <1381566393.7039054.1412626641999.JavaMail.zimbra@redhat.com> In-Reply-To: <20141006195844.ED7D61AEB1@ld9781.wdf.sap.corp> References: <20141006195844.ED7D61AEB1@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922) Thread-Topic: I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt Thread-Index: YluHgyEumeMc8PBPH24lZb6rwGI0hA== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PmD_Ppw551gxgA2Vcx0USaVKPd8 Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 20:17:29 -0000 ----- Original Message ----- > From: "Martin Rex" > To: "Hubert Kario" > Cc: tls@ietf.org > Sent: Monday, 6 October, 2014 9:58:44 PM > Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt > > Hubert Kario wrote: > > > > Only about 1% of servers support only RC4 cipher, 1.5% if you're > > using Firefox[1]. > > > > On the other hand, over 21% of servers will negotiate a RC4 cipher > > in case you're using Firefox (and nearly 18% if you're using > > OpenSSL-like supported cipher list). > > > > So by dropping RC4 from your first ClientHello (in case you do use > > fallback) may as well cut your RC4 usage by over 20%! > > We're talking past each other here. > > I'm perfectly OK with the MUST NOT for the __client__ (!!), and > I will not mind the slightest if (Browser or other) TLS clients that > implement the awkward application-level reconnect fallback logic > for TLS handshake failures start "punishing" the remaining RC4-only > servers with reconnect fallbacks. that doesn't increase security against targeted attacks, which are basically the only ones against which we need protection > My issue is with the IMHO bogus "MUST NOT" for servers. > Servers have no control over the client behaviour, and the current > proposal calls for an unconditional hard failure (equals to > "come back in clear text") rather than interoperating with an > RC4-based TLS cipher suites with installed base clients. thing is that only very specific clients do advertise only RC4, far less than there are RC4 only servers. Cloudflare saw on the order of 0.000002% of connections end up with RC4: http://blog.cloudflare.com/the-web-is-world-wide-or-who-still-needs-rc4/ All from long obsolete clients. Previously they saw on the order of 0.0009%: http://blog.cloudflare.com/killing-rc4-the-long-goodbye/ -- Regards, Hubert Kario From nobody Mon Oct 6 13:24:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FF31A89A3 for ; Mon, 6 Oct 2014 13:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDyHSfzrZG5S for ; Mon, 6 Oct 2014 13:24:13 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93671A8955 for ; Mon, 6 Oct 2014 13:24:12 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 701477A2E0; Mon, 6 Oct 2014 22:24:11 +0200 (CEST) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 6614F432F3; Mon, 6 Oct 2014 22:24:11 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5FB491AEB1; Mon, 6 Oct 2014 22:24:11 +0200 (CEST) In-Reply-To: <1381566393.7039054.1412626641999.JavaMail.zimbra@redhat.com> To: Hubert Kario Date: Mon, 6 Oct 2014 22:24:11 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141006202411.5FB491AEB1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/S9xXVPSNLeyDXMPi5t1Y0NWCyv4 Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 20:24:16 -0000 Hubert Kario wrote: > >> My issue is with the IMHO bogus "MUST NOT" for servers. >> Servers have no control over the client behaviour, and the current >> proposal calls for an unconditional hard failure (equals to >> "come back in clear text") rather than interoperating with an >> RC4-based TLS cipher suites with installed base clients. > > thing is that only very specific clients do advertise only RC4, > far less than there are RC4 only servers. Cloudflare saw on the > order of 0.000002% of connections end up with RC4: > http://blog.cloudflare.com/the-web-is-world-wide-or-who-still-needs-rc4/ > All from long obsolete clients. > > Previously they saw on the order of 0.0009%: > http://blog.cloudflare.com/killing-rc4-the-long-goodbye/ I'm not sure how representative that cloudflare statistic is. But if this is anywhere near the real numbers, that the current "MUST NOT" for server would be clear fear-mongering rather than providing the target audience a sensible information about the trade-off and realistic perspective on the insignificance of the perceived threat. -Martin From nobody Mon Oct 6 15:37:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF061A902E for ; Mon, 6 Oct 2014 15:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4ZRmzWezQNQ for ; Mon, 6 Oct 2014 15:37:56 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C602B1A9044 for ; Mon, 6 Oct 2014 15:37:55 -0700 (PDT) Received: from localhost ([::ffff:91.64.6.209]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 07 Oct 2014 00:37:51 +0200 id 0000000000000086.00000000543319BF.00003513 Date: Tue, 7 Oct 2014 00:37:55 +0200 From: Hanno =?ISO-8859-1?B?QvZjaw==?= To: tls@ietf.org Message-ID: <20141007003755.2b278d34@hboeck.de> In-Reply-To: References: X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-13587-1412635071-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Q8GrPEM_hfMhZqi7seWafAdniwM Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 22:37:58 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-13587-1412635071-0001-2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am Sun, 5 Oct 2014 16:18:50 -0700 schrieb Ryan Carboni : > https://en.wikipedia.org/wiki/Speck_%28cipher%29 Quote: "Speck is a family of lightweight block ciphers publicly released by the NSA in June 2013." Brilliant idea! We also should make the use of Dual EC DRBG mandatory for key generation. --=20 Hanno B=F6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-13587-1412635071-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJUMxnDAAoJEKWIAHK7tR5Ce08QALcxgqRIagNjZeymEKJAxrZj QI3/3z26X7Nrp6BPGDD+73SFkCQkuZKUs+pdB3eyLQ3FcxivnfHJ3PxdRHL7nAq2 aV3uLP5yoddHhc9Rsu6PVwAYvWX/9v7JE5kwoSbbWBnMfXrtV4uwRy3FGSwkwEnr OmhMXQ8Ib4asA4nqvMvaBVJNAJCtTBOhUixEBy04awAQilfqM2W8dbKUl2EdUpJA EFaIMkD7mDtj+890PhwOgcst/Vep1D8WUXtp/OHV6oaNujjITDM8A3EZl20GCOmM 0d0CJ+zraBv4qAICQyd9OmLRiiEotc5AQAD6RaI+CEW8aX+xqsLcrs1xWvOC/uw3 OWGex3yeFoSbRrGpdGekyw06Di1vTYXMDSZTeC9kpLM+e8qkPaWX2O7A4PPkz/vy 1sWE1JWSSO8+1Ekd2iPlfPvoAzHUciLDvseNqceLcdsPeOvV6c/m8pUT/VV9BArS 72xXbO4+Sx8KQ9rFoJ1HMaYjcqf7pXcvcWPWndS3U067kJVDerUEcQvq/6HjVcwF QoGsujCIexdanbf/ch0GrWgMbR2eqOY6x7j6QHj6oVkkGuLjGjldpZcQWt5PGXkD +8orPa66XuL0310xPIkXYuAgUE0ITlfBK6wPQn1UrFhTBsdN/H6BlZPB+4BE0yWu 2ebV17gET32slP9ES9I0 =0rOx -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-13587-1412635071-0001-2-- From nobody Mon Oct 6 22:26:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8D01A9124 for ; Mon, 6 Oct 2014 22:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_ldwMCBKP-B for ; Mon, 6 Oct 2014 22:26:15 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E371A9123 for ; Mon, 6 Oct 2014 22:26:14 -0700 (PDT) Received: from tunnis-2.local (2.67.110.94.mobile.tre.se [2.67.110.94]) by mail.frobbit.se (Postfix) with ESMTPSA id C560522943; Tue, 7 Oct 2014 07:26:11 +0200 (CEST) Message-ID: <54337967.5070702@secworks.se> Date: Tue, 07 Oct 2014 07:25:59 +0200 From: =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Hanno_B=F6ck?= References: <20141007003755.2b278d34@hboeck.de> In-Reply-To: <20141007003755.2b278d34@hboeck.de> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YJeMy4U4Mx7Ep4jfv16tURmbrtE Cc: tls@ietf.org Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: joachim@secworks.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 05:26:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aloha! Hanno Böck wrote: > Am Sun, 5 Oct 2014 16:18:50 -0700 schrieb Ryan Carboni > : > >> https://en.wikipedia.org/wiki/Speck_%28cipher%29 > > Quote: "Speck is a family of lightweight block ciphers publicly > released by the NSA in June 2013." Even more importanyly - SPECK and SIMON (another new lightweight cipher designed by NSA) has been found to be weak against differential crypyanalysis: http://eprint.iacr.org/2013/568.pdf https://eprint.iacr.org/2013/543.pdf Considering that NSA was able to design DES in the 1970ies to be resistant to differential attacks, one almost have to wonder if a new generation of NSA employess have forgotten what the previous generation clearly knew about. So, no: SPECK and SIMON should not be included in TLS. Not because of the provenance, but because they are known to be weak/broken today. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim@secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJUM3lmAAoJEF3cfFQkIuyNasUP/RCeYZA7HgRUmIjCpu7pbO6Z +iA6+7b3Hu0Dyol5ZvsjjK+71ksCxFgwqrDIMO/MC/iy67oJuz3VdFNoqih3I23J FtB/QXOKJy3Ts7mMr9Zl++hC6yQ6Uajjx/ojD3ZdH+gIpqB4XCphM0cx/lfRlJG9 MtMeWGf+ZkQOD17l2A2dFm+xL3AF6H0RE82ESTXXuiUeuk2yZ5iCa8zr8TosZ6qB CeL1HraP4RGbiYd6MCZwxFKsGpPnUeqwj4wlgZj6GtCgC8rZpKY3R2JhuYsCceIH 8iVJ4jUC5b5dYlYQJXFp0RcaTRqaBjbAS7nTXzlUPVoaCnfxnrYi1rnzeEFwfR0K 4LITtl49gkYd4HWKPnSh05QcWhVqEEyA8D3jaGztCnjvShjQKD35WM231QFPYXl5 9vDHA5jUSWO5uMnLi0/4lm5E/MpbV3ku189pMFbJ4O6811ebrOa338UMHm5uQncE OGUmrDieY6OGDD7WmcKEdVq6GCiTuiGahwF4Cy+pAOYiW1N69+y60W6LlwMyWSfu lgufEQtwEoPlGfjl8a9JkndJ+TQIybzqIBq2+CBi8plEI4edM7enXf61+JXugqw3 1jT5INEarvO+RVwXssbqen5o0N16VHSX3TCrseTqc0udI2hQr4WTroCu0YrlMbJQ 4rK2CxFbArpKRymNa9OG =HfwL -----END PGP SIGNATURE----- From nobody Tue Oct 7 11:18:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008881ACEDD for ; Tue, 7 Oct 2014 11:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oK0sSmJi744 for ; Tue, 7 Oct 2014 11:17:57 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F981ACEB4 for ; Tue, 7 Oct 2014 11:17:57 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id em10so8724451wid.16 for ; Tue, 07 Oct 2014 11:17:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=DLJDR8DM226hwocfGABiZLyNpQJzgtgZEBdFZVKAiSo=; b=KyfxRoHk8egn+UWUYJAVmLGjIc9LjBpD6Gb82CwlL7G1nWyQ6q1Txy6E6aK2SZyHwS AnZs8PP0/cCIlgSoCDigBnCyqir5E2v6fBZmfzl5QpVKIjdocdrkKJknjdO2ngfXHzSO ja+FnKLk9wllPxzJunPqy5mVIMrIMGhlS8/m0tEjOQhi4noNDSHvZ6MvOLWuXcvR10U+ JfooieU+MQ/g+BCfhVjrPnuKP6wLjnYF0Yn+B+CwmUH4tbjWUKLkWjPqyaN8nUqp40HG TVwnEFP53144AEJhrF++YCDpFZ54aGM2kUAALLTfDP/fcwf9pNNVXzCRuD0Mc0EP6OWQ nS1Q== X-Gm-Message-State: ALoCoQknX9FekanYJvlugMOLcMahPsTImgKJLvex1LuVE2kKXboPZx4QlFW8CN0X5HDAjzhgbBFx X-Received: by 10.194.62.166 with SMTP id z6mr6779266wjr.44.1412705875630; Tue, 07 Oct 2014 11:17:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.130.130 with HTTP; Tue, 7 Oct 2014 11:17:15 -0700 (PDT) From: Eric Rescorla Date: Tue, 7 Oct 2014 11:17:15 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86e1ece3b2cb0504d93724 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JDRugii1H-UQfT5lpKzKt4KyXCM Subject: [TLS] Pull Request #82: Merge in ECC and Negotiated FF-DHE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 18:17:59 -0000 --047d7b86e1ece3b2cb0504d93724 Content-Type: text/plain; charset=UTF-8 Folks, I've just made Pull Request 82, which implements a number of the changes we discussed in Toronto, including: - Merge in support for ECC from RFC 4492. - Merge in the relevant text from the Finite-Field Diffie-Hellman draft. - Merge the code point spaces for named groups between ECC and FF-DHE (see DKG's message to the list from September 19.) - Rename {Client,Server}KeyExchange to {Client,Server}KeyShare - Add an explicit HelloRetryRequest to reject the client's ClientKeyShare. This was something we discussed and just makes things a lot clearer. Please see the PR at: https://github.com/tlswg/tls13-spec/pull/82 Target merge date October 9. Please comment here or on github if you see issues. Best, -Ekr P.S. Next up is incorporating the session-hash/triple handshake changes. --047d7b86e1ece3b2cb0504d93724 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

I've just made Pu= ll Request 82, which implements a number of
the changes we discus= sed in Toronto, including:

- Merge in support for = ECC from RFC 4492.

- Merge in the relevant text fr= om the Finite-Field Diffie-Hellman
=C2=A0 draft.

- Merge the code point spaces for named groups between ECC and FF-= DHE
=C2=A0 (see DKG's message to the list from September 19.)=

- Rename {Client,Server}KeyExchange to {Client,Se= rver}KeyShare

- Add an explicit HelloRetryRequest = to reject the client's
=C2=A0 ClientKeyShare. This was someth= ing we discussed and just makes
=C2=A0 things a lot clearer.

Please see the PR at:

Target merge date October 9.
=
Please comment here or on github if you see issues.

Best,
-Ekr

P.S. Next up= is incorporating the session-hash/triple handshake
changes.

--047d7b86e1ece3b2cb0504d93724-- From nobody Tue Oct 7 12:35:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE0A1A1A06 for ; Tue, 7 Oct 2014 12:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME9egAcQtEGB for ; Tue, 7 Oct 2014 12:35:15 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AFC61A0104 for ; Tue, 7 Oct 2014 12:35:14 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id E5600402B; Tue, 7 Oct 2014 22:35:12 +0300 (EEST) Date: Tue, 7 Oct 2014 22:35:12 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20141007193512.GA32644@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0s5ezpQ16u98mWbUa1yz61LZOZg Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request #82: Merge in ECC and Negotiated FF-DHE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 19:35:18 -0000 On Tue, Oct 07, 2014 at 11:17:15AM -0700, Eric Rescorla wrote: > Folks, > > I've just made Pull Request 82, which implements a number of > the changes we discussed in Toronto, including: > > - Merge in support for ECC from RFC 4492. Might be a good idea to allow curve to specify a format for ECDHE. This avoids trouble with "exotic" formats (useful for what is expected for CFRG curves[1] and some other high-performance curves). The presently defined ECC curves can use X9.62 formats for ECDHE. Also, note that ClientKeyShare representations are unnegotiable (at least for optimistic round), so one presumably needs to fix the representation (X9.62 compressed?) even for existing groups). > - Rename {Client,Server}KeyExchange to {Client,Server}KeyShare How does the server know to expect CKS? If ClientVersion is 3.4 or higher and there is no first flight extension in ClientHello? Due to how TLS handshake and underlying transport works, the last message in flight can not be optional. And sending CKS as-is would cause TLS 1.2 server to blow up. > - Add an explicit HelloRetryRequest to reject the client's > ClientKeyShare. This was something we discussed and just makes > things a lot clearer. Now you have duplicate ClientHello and parts of ServerHello, both of which must be checked for constency. If you don't, you have a security hole (especially if one restarts hash). I would rather not have such traps in the spec. And since one needs copies of CH and SH to check them, sending them again is completely redundant. Also, omitting the superfluous CH and SH-parts will let one omit the redundant key shares. In DTLS, those retransmissions can be quite expensive (network I/O can be way more expensive than you think). Also, restarting the handshake, one must implement group selection so that one can't get stuff like this: C->S: Hello, Groups X, Y, Z. S->C: Try again: Use group W. C->S: Hello, Groups X, Y, Z, W. S->C: Try again: Use group U. ... Other notes: Named_groups is not noted to be mandatory. What happens if it is missing? Fatal error? Optimistic CKS has all supported groups? The optimistic nature of CKS means that Supported Point Formats can't really be applied to ECDHE key exchange, only to signatures. Also, in Supported Point Formats, if it does not apply to ECDHE (due to the problem above), what does it apply to? The only another points are in host key, which is inside certificate, and thus one would have to drive certificate choice off SPF. The stuff copied to section "Elliptic Curve Diffie-Hellman" is likely totally inapporiate for CFRG curves. One idea would be to encode the output point as it would be sent on the wire in CKS/SKS. [1] I expect those curves to be of "new" shapes, and X9.62 point encoding can't properly handle those (especially not compresion). -Ilari From nobody Tue Oct 7 14:46:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F67D1A88C2 for ; Tue, 7 Oct 2014 14:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdXp9mXBbj_9 for ; Tue, 7 Oct 2014 14:46:31 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5E51A88CC for ; Tue, 7 Oct 2014 14:46:24 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id s18so7342110lam.9 for ; Tue, 07 Oct 2014 14:46:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IDujwGswGQKQ1ebH6Bx8Nh2/KIO5bIrr37WbTILYAAU=; b=HDQzWWtiyEORGYXb5wAZyd38dDV2PWO4Ow6WRS+6GkKpsYb0GbQxgv/BteubH/RqJ/ jjtsB9zpbs2xMfuz1Blf1K2ABE9ZBvqiJTU3pb9qsI3U0USdfyVjdc7aPZxqvnhteaeb A+LVwUiUis1y73UoN7MlgpSsTwE+BTOTHDfGOYoYh65VXCeMqUsQhTQoKGGU4MJYa3c9 lLbnjFTck64mejK5OzcOIGPtv86CFHYA+3LOLtuXOraBdktoCHodlN0OQkDi+NiuJejS nuQGsVVjG+HaoQrLQDw9pfkAgZKsNMT5MdRSkbHe3Aem96Khj3oYBOLL/JHifY6eYhuq cSVg== X-Gm-Message-State: ALoCoQmCjaHUOwVrfjP6Vyt8sZdqJHo53TFLRuJY8234wGvQRYPmwBx6ARCEIEKyH5yDH88JE2vW X-Received: by 10.152.42.194 with SMTP id q2mr7058761lal.75.1412718383191; Tue, 07 Oct 2014 14:46:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.255.132 with HTTP; Tue, 7 Oct 2014 14:45:43 -0700 (PDT) In-Reply-To: <20141007193512.GA32644@LK-Perkele-VII> References: <20141007193512.GA32644@LK-Perkele-VII> From: Eric Rescorla Date: Tue, 7 Oct 2014 14:45:43 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c3557a65ea480504dc21d2 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rywFvm4MOxu9-fSgWPzcm2RPZTg Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request #82: Merge in ECC and Negotiated FF-DHE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:46:34 -0000 --001a11c3557a65ea480504dc21d2 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 7, 2014 at 12:35 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Tue, Oct 07, 2014 at 11:17:15AM -0700, Eric Rescorla wrote: > > Folks, > > > > I've just made Pull Request 82, which implements a number of > > the changes we discussed in Toronto, including: > > > > - Merge in support for ECC from RFC 4492. > > Might be a good idea to allow curve to specify a format for ECDHE. > This avoids trouble with "exotic" formats (useful for what is > expected for CFRG curves[1] and some other high-performance curves). > Yes, see the somewhat opaquely worded note here: https://github.com/tlswg/tls13-spec/pull/82/files#diff-9d84740dcc569a0a5a359d0fba461a05R1968 > The presently defined ECC curves can use X9.62 formats for ECDHE. > > Also, note that ClientKeyShare representations are unnegotiable > (at least for optimistic round), so one presumably needs to fix > the representation (X9.62 compressed?) even for existing groups). IIRC, the points are self-describing as to whether they are compressed or not, so the client has to choose, but he might guess wrong as he does with the groups. I would actually prefer to fix the representation if that's possible, but I figure that's a separable question. > > - Rename {Client,Server}KeyExchange to {Client,Server}KeyShare > > How does the server know to expect CKS? If ClientVersion is 3.4 > or higher and there is no first flight extension in ClientHello? > Yes. > Due to how TLS handshake and underlying transport works, the > last message in flight can not be optional. And sending CKS as-is > would cause TLS 1.2 server to blow up. Yes. You always must send it either in EarlyData or otherwise. And if you don't know, it has to go in the extension for backwards compatibility. > > > - Add an explicit HelloRetryRequest to reject the client's > > ClientKeyShare. This was something we discussed and just makes > > things a lot clearer. > > Now you have duplicate ClientHello and parts of ServerHello, both > of which must be checked for constency. If you don't, you have a > security hole (especially if one restarts hash). > > I would rather not have such traps in the spec. > > And since one needs copies of CH and SH to check them, sending > them again is completely redundant. > Can you elaborate on your concern here? > Also, omitting the superfluous CH and SH-parts will let one omit > the redundant key shares. > As I think I said previously, there was consensus to use this design at the Denver interim in the name of consistency. All I've done here is change the server's first ServerHello to a HelloRetryRequest, which I believe is consistent with that decision. If the WG consensus is to change this, I'll make the change. Other notes: > > Named_groups is not noted to be mandatory. What happens if it > is missing? Fatal error? Optimistic CKS has all supported > groups? > My bad. This was supposed to be mandatory but it got lost in an editorial pass. I will fix. > The optimistic nature of CKS means that Supported Point Formats > can't really be applied to ECDHE key exchange, only to > signatures. > I don't believe this is true. Supported points is the list of points that you will let the other side send, not that you can send. See: https://github.com/tlswg/tls13-spec/pull/82/files#diff-9d84740dcc569a0a5a359d0fba461a05R2394 So, what you are saying is "regardless of what formats I sent you, send me X". Also, Supported Points can be used by the server in the HelloRetryRequest to indicate if the client sent an inappropriate point format. I recognize all this point negotiation is silly and as I said, I would be fine if we just required one form. See issue: https://github.com/tlswg/tls13-spec/issues/80 Also, in Supported Point Formats, if it does not apply to > ECDHE (due to the problem above), what does it apply to? > The only another points are in host key, which is inside > certificate, and thus one would have to drive certificate > choice off SPF. > Yes, 4492 requires this: " The server constructs an appropriate certificate chain and conveys it to the client in the Certificate message. If the client has used a Supported Elliptic Curves Extension, the public key in the server's certificate MUST respect the client's choice of elliptic curves; in particular, the public key MUST employ a named curve (not the same curve as an explicit curve) unless the client has indicated support for explicit curves of the appropriate type. If the client has used a Supported Point Formats Extension, both the server's public key point and (in the case of an explicit curve) the curve's base point MUST respect the client's choice of point formats. (A server that cannot satisfy these requirements MUST NOT choose an ECC cipher suite in its ServerHello message.)" > The stuff copied to section "Elliptic Curve Diffie-Hellman" > is likely totally inapporiate for CFRG curves. One idea > would be to encode the output point as it would be sent > on the wire in CKS/SKS. I've filed the following issue to deal with this when those curves pop out: https://github.com/tlswg/tls13-spec/issues/83 -Ekr --001a11c3557a65ea480504dc21d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 7, 2014 at 12:35 PM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
On Tue, O= ct 07, 2014 at 11:17:15AM -0700, Eric Rescorla wrote:
> Folks,
>
> I've just made Pull Request 82, which implements a number of
> the changes we discussed in Toronto, including:
>
> - Merge in support for ECC from RFC 4492.

Might be a good idea to allow curve to specify a format for ECDHE. This avoids trouble with "exotic" formats (useful for what is
expected for CFRG curves[1] and some other high-performance curves).

Yes, see the somewhat opaquely worded note he= re:
=C2=A0
The presently defined ECC curves can use X9.62 formats for ECDHE.

Also, note that ClientKeyShare representations are unnegotiable
(at least for optimistic round), so one presumably needs to fix
the representation (X9.62 compressed?) even for existing groups).

IIRC, the points are self-describing as to whether t= hey are compressed
or not, so the client has to choose, but he mi= ght guess wrong as
he does with the groups. I would actually pref= er to fix the representation
if that's possible, but I figure= that's a separable question.


> - Rename {Client,Server}KeyExchange to {Client,Server}KeyShare

How does the server know to expect CKS? If ClientVersion is 3.4
or higher and there is no first flight extension in ClientHello?

Yes.

=C2=A0
Due to how TLS handshake and underlying transport works, the
last message in flight can not be optional. And sending CKS as-is
would cause TLS 1.2 server to blow up.

Yes.= You always must send it either in EarlyData or otherwise. And if
you don't know, it has to go in the extension for backwards compatibil= ity.


=C2=A0
=
> - Add an explicit HelloRetryRequest to reject the client's
>=C2=A0 =C2=A0ClientKeyShare. This was something we discussed and just m= akes
>=C2=A0 =C2=A0things a lot clearer.

Now you have duplicate ClientHello and parts of ServerHello, both of which must be checked for constency. If you don't, you have a
security hole (especially if one restarts hash).

I would rather not have such traps in the spec.

And since one needs copies of CH and SH to check them, sending
them again is completely redundant.

Can= you elaborate on your concern here?

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> Also, omitting the superfluous CH and SH-parts will let one omit
the redundant key shares.

As I think I = said previously, there was consensus to use this design
at the De= nver interim in the name of consistency. All I've done here
i= s change the server's first ServerHello to a HelloRetryRequest,
which I believe is consistent with that decision. If the WG consensus
is to change this, I'll make the change.


Other notes:

Named_groups is not noted to be mandatory. What happens if it
is missing? Fatal error? Optimistic CKS has all supported
groups?

My bad. This was supposed to be= mandatory but it got lost in an
editorial pass. I will fix.

=C2=A0
The optimistic nature of CKS means that Supported Point Formats
can't really be applied to ECDHE key exchange, only to
signatures.

I don't believe this is= true. Supported points is the list of points that
you will let t= he other side send, not that you can send. See:

https://github.com/tlswg/tls1= 3-spec/pull/82/files#diff-9d84740dcc569a0a5a359d0fba461a05R2394

So, what you are saying is "regardless of what f= ormats I sent you,
send me X". Also, Supported Points can be= used by the server
in the HelloRetryRequest to indicate if the c= lient sent an inappropriate
point format.

I recognize all this point negotiation is silly and as I said, I would be=
fine if we just required one form. See issue:


Also, in Supported Point Formats, if it does not apply to
ECDHE (due to the problem above), what does it apply to?
The only another points are in host key, which is inside
certificate, and thus one would have to drive certificate
choice off SPF.

Yes, 4492 requires this= :

" The server constructs an appropriate certificate chain and= conveys it
   to the =
client in the Certificate message.  If the client has used a
   Supported Elliptic Curves Extension, the public key in the server's
   certificate MUST respect the client's choice of elliptic curves; in
   particular, the public key MUST employ a named curve (not the same
   curve as an explicit curve) unless the client has indicated support
   for explicit curves of the appropriate type.  If the client has used
   a Supported Point Formats Extension, both the server's public key
   point and (in the case of an explicit curve) the curve's base point
   MUST respect the client's choice of point formats.  (A server that
   cannot satisfy these requirements MUST NOT choose an ECC cipher suite
   in its ServerHello message.)"


=C2=A0

The stuff copied to section "Elliptic Curve Diffie-Hellman"

is likely totally inapporiate for CFRG curves. One idea

would be to encode the output point as it would be sent

on the wire in CKS/SKS.

I've filed the =
following issue to deal with this when those curves
--001a11c3557a65ea480504dc21d2-- From nobody Tue Oct 7 16:53:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C271A8AA5 for ; Tue, 7 Oct 2014 16:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StzpgW8nJCFF for ; Tue, 7 Oct 2014 16:53:24 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.59.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0A91A8AA4 for ; Tue, 7 Oct 2014 16:53:24 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 0D9983CF5F76C; Tue, 7 Oct 2014 18:53:24 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway12.websitewelcome.com (Postfix) with ESMTP id F0C8C3CF5F748 for ; Tue, 7 Oct 2014 18:53:23 -0500 (CDT) Received: from [173.73.121.234] (port=55003 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XbeZH-0004Rs-GU for tls@ietf.org; Tue, 07 Oct 2014 18:53:23 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Oct 2014 19:53:21 -0400 References: <20141007184822.18585.49773.idtracker@ietfa.amsl.com> To: "TLS@ietf.org (tls@ietf.org)" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.234 X-Exim-ID: 1XbeZH-0004Rs-GU X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [173.73.121.234]:55003 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-V0PGc5rs7n7ciNgDIjduoo9fk4 Subject: [TLS] Fwd: Last Call: (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 23:53:26 -0000 Just in case you=92re not on the announce list. spt Begin forwarded message: > From: The IESG > Subject: Last Call: (Application Layer = Protocol Negotiation (ALPN) labels for Session Traversal Utilities for = NAT (STUN) Usages) to Proposed Standard > Date: October 07, 2014 at 14:48:22 EDT > To: IETF-Announce > Cc: tram@ietf.org > Reply-To: ietf@ietf.org >=20 >=20 > The IESG has received a request from the TURN Revised and Modernized = WG > (tram) to consider the following document: > - 'Application Layer Protocol Negotiation (ALPN) labels for Session > Traversal Utilities for NAT (STUN) Usages' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-10-21. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > Application Layer Protocol Negotiation (ALPN) labels for Session > Traversal Utilities for NAT (STUN) usages, such as Traversal Using > Relays around NAT (TURN) and NAT discovery, are defined in this > document to allow an application layer negotiate STUN usages within > the Transport Layer Security (TLS) connection. ALPN protocol > identifiers defined in this document apply to both TLS and Datagram > Transport Layer Security (DTLS). >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-tram-alpn/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-tram-alpn/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 From nobody Wed Oct 8 13:08:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E4B1A02D2 for ; Wed, 8 Oct 2014 13:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm_4lcpmRK28 for ; Wed, 8 Oct 2014 13:08:31 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8F31A02E6 for ; Wed, 8 Oct 2014 13:08:31 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B08FE48592 for ; Wed, 8 Oct 2014 20:08:30 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id A559F48569 for ; Wed, 8 Oct 2014 20:08:30 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub7.dfw01.corp.akamai.com [172.27.25.73]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id A2C981E045 for ; Wed, 8 Oct 2014 20:08:30 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub7.dfw01.corp.akamai.com ([172.27.25.73]) with mapi; Wed, 8 Oct 2014 15:08:29 -0500 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Wed, 8 Oct 2014 15:08:27 -0500 Thread-Topic: In ALPN, why is server response a MAY? Thread-Index: Ac/jM3qlrK6MYjM7SyyET+JbT0RlRg== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD096D3@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vqy0oEsoESo0uS5FvhISEE8EEEQ Subject: [TLS] In ALPN, why is server response a MAY? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 20:08:33 -0000 In the ALPN definition (RFC 7301), section 3.1,=20 Servers that receive a ClientHello containing the "application_layer_protocol_negotiation" extension MAY return a suitable protocol selection response to the client.=20 Why isn't that a MUST?=20 -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Wed Oct 8 13:52:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722EF1A037F for ; Wed, 8 Oct 2014 13:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvO7bd6FaKUZ for ; Wed, 8 Oct 2014 13:51:59 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACFF21A037C for ; Wed, 8 Oct 2014 13:51:58 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id q1so9349748lam.18 for ; Wed, 08 Oct 2014 13:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lxHrpNXinaLejkiko+XwZn9cI7E+1XJu10UXoZFYVXU=; b=kIPQiWzO7kTY62UYgsLULfRjFSg7tMcRVLgU5ZwVvY4GGolCEhvLAHexoqiKg61c1W xpx796yfUuPXvx3K0ShieVWW+iNh4hsW7pvQyHHZiQ4BLc7Q1dYApwT8IksjkukHScnx F8s1gpePmKHB+DmIwXWDHxpxUqX8G+pRbt/qT8R6MSKq03N0svM+2G1DSbcTmWBzvF2S ZShi9Zlwqq0ijcwe8C2oNwc2u8MbTESHjuBBVSF5sd9gljjR6gILHOyFplk97rctMcHs PKDSwyrbddKpsonmfA4UcUgHIBI4T1884l60JKaXl1BbundF9r7BOL+tjdOmnv3BsyvK FchA== MIME-Version: 1.0 X-Received: by 10.112.142.104 with SMTP id rv8mr12949558lbb.59.1412801516962; Wed, 08 Oct 2014 13:51:56 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Wed, 8 Oct 2014 13:51:56 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD096D3@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD096D3@USMBX1.msg.corp.akamai.com> Date: Wed, 8 Oct 2014 13:51:56 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Er0L0fe-fL3vWyG6Rob7DxANOCw Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] In ALPN, why is server response a MAY? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 20:52:00 -0000 On 8 October 2014 13:08, Salz, Rich wrote: > In the ALPN definition (RFC 7301), section 3.1, > Servers that receive a ClientHello containing the > "application_layer_protocol_negotiation" extension MAY return a > suitable protocol selection response to the client. > > Why isn't that a MUST? I'm guessing that servers are able to pretend not to support ALPN at their convenience. From nobody Wed Oct 8 14:03:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB1E1A03A2 for ; Wed, 8 Oct 2014 14:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT8tX7QewH9S for ; Wed, 8 Oct 2014 14:03:57 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 01CE01A03A8 for ; Wed, 8 Oct 2014 14:03:56 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3F1781658BB; Wed, 8 Oct 2014 21:03:56 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 347CA1657D5; Wed, 8 Oct 2014 21:03:56 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub5.dfw01.corp.akamai.com [172.27.25.71]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 32BB598041; Wed, 8 Oct 2014 21:03:56 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub5.dfw01.corp.akamai.com ([172.27.25.71]) with mapi; Wed, 8 Oct 2014 16:03:56 -0500 From: "Salz, Rich" To: Martin Thomson Date: Wed, 8 Oct 2014 16:03:54 -0500 Thread-Topic: [TLS] In ALPN, why is server response a MAY? Thread-Index: Ac/jObSu7uLZXnBVTZ6hqNUETtytJAAAZbhQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD0971A@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD096D3@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/23KdzvUeTMejqVpU2i0fuVAS2QY Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] In ALPN, why is server response a MAY? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 21:03:58 -0000 PiBJJ20gZ3Vlc3NpbmcgdGhhdCBzZXJ2ZXJzIGFyZSBhYmxlIHRvIHByZXRlbmQgbm90IHRvIHN1 cHBvcnQgQUxQTiBhdCB0aGVpcg0KPiBjb252ZW5pZW5jZS4NCg0KU28gdGhlbiBhIGNsaWVudCBz aG91bGQgYXNzdW1lIHRoYXQgQUxQTiBpc24ndCBzdXBwb3J0ZWQgYW5kIHRoZWlyIHJlcXVlc3Qg d2Fzbid0IGhvbm9yZWQ/XA0KDQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlciwg QWthbWFpIFRlY2hub2xvZ2llcw0KSU06IHJzYWx6QGphYmJlci5tZSBUd2l0dGVyOiBSaWNoU2Fs eg0KDQo= From nobody Wed Oct 8 14:07:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21C91A0369 for ; Wed, 8 Oct 2014 14:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wtw6a7LlO_0t for ; Wed, 8 Oct 2014 14:07:44 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C26C1A0386 for ; Wed, 8 Oct 2014 14:07:44 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Wed, 8 Oct 2014 21:07:43 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1044.008; Wed, 8 Oct 2014 21:07:43 +0000 From: Andrei Popov To: Martin Thomson , "Salz, Rich" Thread-Topic: [TLS] In ALPN, why is server response a MAY? Thread-Index: Ac/jM3qlrK6MYjM7SyyET+JbT0RlRgABjeUAAABgb4A= Date: Wed, 8 Oct 2014 21:07:43 +0000 Message-ID: <6de2a3bdcddb4025893e09fba4257b48@BL2PR03MB419.namprd03.prod.outlook.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD096D3@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB419; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0358535363 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(199003)(51704005)(24454002)(13464003)(15975445006)(76482002)(99396003)(97736003)(107046002)(19580395003)(86362001)(19580405001)(4396001)(80022003)(99286002)(50986999)(106356001)(92566001)(105586002)(108616004)(101416001)(120916001)(54356999)(74316001)(46102003)(76176999)(31966008)(2656002)(21056001)(95666004)(64706001)(85852003)(86612001)(85306004)(33646002)(76576001)(40100002)(20776003)(122556002)(87936001)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q8mnagAJ81DV3d4ao5qBO4owpGU Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] In ALPN, why is server response a MAY? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 21:07:46 -0000 Also, servers and clients have more than one application negotiation mechan= ism available. As long as this is the case, servers get to choose which app= lication negotiation mechanism to use. E.g. if a server receives a list of = ALPN IDs and does not like any of them, the server might choose to give NPN= a try rather than terminating the handshake right away. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Wednesday, October 8, 2014 1:52 PM To: Salz, Rich Cc: TLS@ietf.org (tls@ietf.org) Subject: Re: [TLS] In ALPN, why is server response a MAY? On 8 October 2014 13:08, Salz, Rich wrote: > In the ALPN definition (RFC 7301), section 3.1, > Servers that receive a ClientHello containing the > "application_layer_protocol_negotiation" extension MAY return a > suitable protocol selection response to the client. > > Why isn't that a MUST? I'm guessing that servers are able to pretend not to support ALPN at their = convenience. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Oct 8 14:23:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C531A19FE for ; Wed, 8 Oct 2014 14:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C1OfHJh36mm for ; Wed, 8 Oct 2014 14:23:15 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE46C1A1A1F for ; Wed, 8 Oct 2014 14:23:14 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Wed, 8 Oct 2014 21:23:12 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1044.008; Wed, 8 Oct 2014 21:23:12 +0000 From: Andrei Popov To: "Salz, Rich" , Martin Thomson Thread-Topic: [TLS] In ALPN, why is server response a MAY? Thread-Index: Ac/jM3qlrK6MYjM7SyyET+JbT0RlRgABjeUAAABq/gAAAGiHsA== Date: Wed, 8 Oct 2014 21:23:12 +0000 Message-ID: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD096D3@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD0971A@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD0971A@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB420; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0358535363 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(189002)(377454003)(74316001)(86362001)(80022003)(33646002)(97736003)(105586002)(86612001)(85306004)(107046002)(95666004)(106356001)(99286002)(20776003)(31966008)(92566001)(21056001)(46102003)(122556002)(2656002)(64706001)(101416001)(87936001)(76576001)(76176999)(50986999)(85852003)(19580395003)(4396001)(15975445006)(54356999)(120916001)(76482002)(40100002)(99396003)(108616004)(19580405001)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SS01yMmWd8TuMBgr13TakKKf3Sc Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] In ALPN, why is server response a MAY? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 21:23:18 -0000 If the server does not reply to ALPN, I think a client can: a) Attempt to proceed with some default application protocol (likely HTTP/1= .1 for Web browsers), or b) Use alternative application protocol negotiation mechanism, if available= (e.g. application-specific negotiation after TLS handshake), or c) Terminate the handshake if there is no useful default and no alternative= protocol negotiation mechanism. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Salz, Rich Sent: Wednesday, October 8, 2014 2:04 PM To: Martin Thomson Cc: TLS@ietf.org (tls@ietf.org) Subject: Re: [TLS] In ALPN, why is server response a MAY? > I'm guessing that servers are able to pretend not to support ALPN at=20 > their convenience. So then a client should assume that ALPN isn't supported and their request = wasn't honored?\ -- Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Oct 8 14:27:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90CB1A0410 for ; Wed, 8 Oct 2014 14:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfO13HQrqn8Y for ; Wed, 8 Oct 2014 14:27:42 -0700 (PDT) Received: from smtp1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4366E1A039C for ; Wed, 8 Oct 2014 14:27:42 -0700 (PDT) Received: from [192.168.178.34] (109.125.75.212.dynamic.cablesurf.de [109.125.75.212]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 18DC319CA810 for ; Wed, 8 Oct 2014 23:27:39 +0200 (CEST) Message-ID: <5435AC4A.8010205@net.in.tum.de> Date: Wed, 08 Oct 2014 23:27:38 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: tls@ietf.org References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <542D850E.2060900@akr.io> <64cfd9c21a3f430287b7a0d30908b007@BL2PR03MB419.namprd03.prod.outlook.com> In-Reply-To: <64cfd9c21a3f430287b7a0d30908b007@BL2PR03MB419.namprd03.prod.outlook.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n-Sk4SSVKBS4Q8PVfZ28-Nsa9tA Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 21:27:44 -0000 Hi, > 2. "TLS servers MUST NOT select an RC4 cipher suite" is too > strict/constraining/hard to deploy/etc. If we removed this MUST NOT, > this would not be a prohibiting-rc4 draft, but a best practice > recommendation. We have TLS-BCP for recommendations. The idea of > prohibiting-rc4 is to completely remove a weak cipher suite. The BCP MUST NOTs RC4. It also MUST NOTs the NULL cipher, but says clearly that some scenarios require it, and these are not in scope. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18010 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Wed Oct 8 14:38:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179EF1A1A6E for ; Wed, 8 Oct 2014 14:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckSyYushhqtX for ; Wed, 8 Oct 2014 14:37:58 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1304A1A1A63 for ; Wed, 8 Oct 2014 14:37:57 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id le20so7678119vcb.12 for ; Wed, 08 Oct 2014 14:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IAh9lzAGMflvZUYYBbvccAvkjs1FC874AfBubHjPwVg=; b=FnIN5eBrt0TMDyXtianqBzOPfwspf5kpmVvyq8pbxmfrLoWzNeSV/GvJZx+Q8cxCxk /ZRh7MjrcLgQK8CtB2Dmb0w9D314SK8qwrXu1gLgTnLVy6QT3zmWStFeNh5CzvM7IwFR 9llOMdJyWMB89stQIyIS/fx1fV37VabHdbGpAKimQVyI2WS1IhxmduwICYUMOfkKv5F7 LhIGnogJ4+4UIRBmlOA8rKLxK+cOQiItD9to/0CNn2EhSBTqSBprOini4x3TtmXgucTW Gb3TOQpg9Uq20NeISn42tjhSJWuqUn67C2t6lNb12QpBz7QXGYyJJFAAtZze9PfHEf+1 JKxg== MIME-Version: 1.0 X-Received: by 10.52.103.8 with SMTP id fs8mr11636193vdb.77.1412804276985; Wed, 08 Oct 2014 14:37:56 -0700 (PDT) Received: by 10.220.58.136 with HTTP; Wed, 8 Oct 2014 14:37:56 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD096D3@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD096D3@USMBX1.msg.corp.akamai.com> Date: Thu, 9 Oct 2014 01:37:56 +0400 Message-ID: From: Mohamad Badra To: "Salz, Rich" Content-Type: multipart/alternative; boundary=047d7b86ef2e1124790504f02121 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/y5_jbhFY00TwtCdmhhtHh37YhFk Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] In ALPN, why is server response a MAY? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 21:38:00 -0000 --047d7b86ef2e1124790504f02121 Content-Type: text/plain; charset=ISO-8859-1 Backward compatibility is one of the main reasons Best regards Badra On Thu, Oct 9, 2014 at 12:08 AM, Salz, Rich wrote: > In the ALPN definition (RFC 7301), section 3.1, > Servers that receive a ClientHello containing the > "application_layer_protocol_negotiation" extension MAY return a > suitable protocol selection response to the client. > > Why isn't that a MUST? > > -- > Principal Security Engineer, Akamai Technologies > IM: rsalz@jabber.me Twitter: RichSalz > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7b86ef2e1124790504f02121 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Backward compatibility is one of the main reasons
Best= regards
Badra

On Thu, Oct 9, 2014 at 12:08 AM, Salz, Rich <rsalz@akama= i.com> wrote:
In the ALPN d= efinition (RFC 7301), section 3.1,
=A0 =A0 =A0 =A0 Servers that receive a ClientHello containing the
=A0 =A0 =A0 =A0 =A0"application_layer_protocol_negotiation" exten= sion MAY return a
=A0 =A0 =A0 =A0 =A0suitable protocol selection response to the client.

Why isn't that a MUST?

--
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSal= z


_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--047d7b86ef2e1124790504f02121-- From nobody Wed Oct 8 14:39:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B711A1A7E for ; Wed, 8 Oct 2014 14:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhMxD62G_i0r for ; Wed, 8 Oct 2014 14:39:24 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id CB0451A1A80 for ; Wed, 8 Oct 2014 14:39:24 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 29F412853F; Wed, 8 Oct 2014 21:39:24 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 164962853B; Wed, 8 Oct 2014 21:39:24 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub1.dfw01.corp.akamai.com [172.27.25.75]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id EF68D8004E; Wed, 8 Oct 2014 21:39:23 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub1.dfw01.corp.akamai.com ([172.27.25.75]) with mapi; Wed, 8 Oct 2014 16:39:23 -0500 From: "Salz, Rich" To: Mohamad Badra Date: Wed, 8 Oct 2014 16:39:22 -0500 Thread-Topic: [TLS] In ALPN, why is server response a MAY? Thread-Index: Ac/jQCtvhLG/IgAeQdSsrE3NckSQvwAAA9Pg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD0972F@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD096D3@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Fk7x5ZrZyR9m-PVC1Te14hs7Kxs Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] In ALPN, why is server response a MAY? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 21:39:26 -0000 > Backward compatibility is one of the main reasons I don't understand that. The client SENT an ALPN. So what is the compatib= ility issue? -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Wed Oct 8 14:48:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A4B1A1A72 for ; Wed, 8 Oct 2014 14:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geHt7vGjw9y1 for ; Wed, 8 Oct 2014 14:48:20 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B141A1A6F for ; Wed, 8 Oct 2014 14:48:19 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id id10so8426vcb.6 for ; Wed, 08 Oct 2014 14:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LhVrjgaM9bWjw16dItiMniX+uM8EFUAqHS13KfBAtTQ=; b=vx9VM/kHtfgd0VWzJKbAACk06Ln0G8cV9RxhhB/dL81ilSnHlJ5uI4ziwvEL9lwtKQ gWf9Yk/FglWUFtAmnP/gFFEcYeQZ2/uU2gHXMESxnKzSPUjXLigU41js37ON+GI6gtc9 UQ/odIzvYTA6fRYPwwbmm+bS0BpN/DGVpupC8wCoOS+T7OMYxJ3SEPsp109k0F7edyaF f8FOmoR83N8Sr3APns2XgQK6ueWCG3iiSYvYg1LzPaqjJsMn832VP9fkD1nqs1L/cGVz BlYlHE558Ma7YBY57xOFhxnUz5JHBF6Yj1KSWnR06WbS5czsYSjFXAe6GUTknEsiu3Ki qaVw== MIME-Version: 1.0 X-Received: by 10.221.41.2 with SMTP id ts2mr13994094vcb.23.1412804899173; Wed, 08 Oct 2014 14:48:19 -0700 (PDT) Received: by 10.220.58.136 with HTTP; Wed, 8 Oct 2014 14:48:19 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD0972F@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD096D3@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD0972F@USMBX1.msg.corp.akamai.com> Date: Thu, 9 Oct 2014 01:48:19 +0400 Message-ID: From: Mohamad Badra To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11339f5826fca00504f046df Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kPV-5pDi7ejPZspMmCsXb_MGew8 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] In ALPN, why is server response a MAY? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 21:48:21 -0000 --001a11339f5826fca00504f046df Content-Type: text/plain; charset=ISO-8859-1 This means that TLS clients that support the extension can talk to TLS servers that do not support the extensions, and vice versa. TLS extensions are designed to be backwards compatible. Best regards Badra On Thu, Oct 9, 2014 at 1:39 AM, Salz, Rich wrote: > > Backward compatibility is one of the main reasons > > I don't understand that. The client SENT an ALPN. So what is the > compatibility issue? > -- > Principal Security Engineer, Akamai Technologies > IM: rsalz@jabber.me Twitter: RichSalz > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11339f5826fca00504f046df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This means that TLS clients that support the extension can= talk to TLS servers that do not support the extensions, and vice versa. TL= S extensions are designed to be backwards compatible.

Bes= t regards
Badra=A0

On Thu, Oct 9, 2014 at 1:39 AM, Salz, Ri= ch <rsalz@akamai.com> wrote:
> Backward compatibility is one of the main reasons
I don't understand that.=A0 The client SENT an ALPN.=A0 So what = is the compatibility issue?
--
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSal= z

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--001a11339f5826fca00504f046df-- From nobody Wed Oct 8 14:53:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B901A1A82 for ; Wed, 8 Oct 2014 14:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBa5g0EcO8W6 for ; Wed, 8 Oct 2014 14:53:11 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id AF69D1A1A7E for ; Wed, 8 Oct 2014 14:53:11 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 336671658B1; Wed, 8 Oct 2014 21:53:11 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 1ECE11658AD; Wed, 8 Oct 2014 21:53:11 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub2.dfw01.corp.akamai.com [172.27.25.76]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 1C7D698042; Wed, 8 Oct 2014 21:53:11 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub2.dfw01.corp.akamai.com ([172.27.25.76]) with mapi; Wed, 8 Oct 2014 16:53:10 -0500 From: "Salz, Rich" To: Mohamad Badra Date: Wed, 8 Oct 2014 16:53:09 -0500 Thread-Topic: [TLS] In ALPN, why is server response a MAY? Thread-Index: Ac/jQZQ0z71/5XwwR4SVEFt9nUkYugAAFzTQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD09732@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD096D3@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD0972F@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71D2FD09732USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/t_AEOgHG8Xbs0etVyqPgWYtB3s0 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] In ALPN, why is server response a MAY? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 21:53:14 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D2FD09732USMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That doesn't make sense. TLS already says is the server doesn't know an ex= tension it should ignore it. So why have an extension and define a response= that is a MAY? As Andrei suggested, you might want to defer to other nego= tiation. Well, okay, but it seems hacky. By making the response a MAY, th= e client doesn't know if it's unsupported, or supported, or supported and r= equest was granted. So it seems like if the response doesn't come back, th= e client MUST treat it as if the server does not support ALPN. -- Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D2FD09732USMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That does= n’t make sense.  TLS already says is the server doesn’t kn= ow an extension it should ignore it. So why have an extension and define a = response that is a MAY?  As Andrei suggested, you might want to defer = to other negotiation.  Well, okay, but it seems hacky.  By making= the response a MAY, the client doesn’t know if it’s unsupporte= d, or supported, or supported and request was granted.  So it seems li= ke if the response doesn’t come back, the client MUST treat it as if = the server does not support ALPN.

 

-- 

Principal Security Engineer= , Akamai Technologies

IM: = rsalz@jabber.= me Twitter: RichSalz

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D2FD09732USMBX1msgcorp_-- From nobody Thu Oct 9 00:53:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8E01ABC0F for ; Thu, 9 Oct 2014 00:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U25-4m1Mu7tO for ; Thu, 9 Oct 2014 00:53:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467691A90CF for ; Thu, 9 Oct 2014 00:53:37 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s997rXE6014192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 9 Oct 2014 03:53:33 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s997rVfs015798 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2014 03:53:32 -0400 Message-ID: <1412841210.13048.3.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "Salz, Rich" Date: Thu, 09 Oct 2014 09:53:30 +0200 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD09732@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD096D3@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD0972F@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD09732@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MTxDz5LNMXcWdAgJSBruBTAvmqI Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] In ALPN, why is server response a MAY? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 07:53:38 -0000 On Wed, 2014-10-08 at 16:53 -0500, Salz, Rich wrote: > That doesn’t make sense. TLS already says is the server doesn’t know > an extension it should ignore it. So why have an extension and define > a response that is a MAY? This is how all extensions are being defined. That way the backwards compatibility is explicit as Mohamad said. regards, Nikos From nobody Thu Oct 9 04:27:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F9B1ACD6F for ; Thu, 9 Oct 2014 04:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMo08ifrFWHN for ; Thu, 9 Oct 2014 04:27:25 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.56.195.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E481ACD6B for ; Thu, 9 Oct 2014 04:27:25 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id A55016963612C; Thu, 9 Oct 2014 06:27:22 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 932F4696360E0 for ; Thu, 9 Oct 2014 06:27:22 -0500 (CDT) Received: from [173.73.121.234] (port=63916 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XcBsQ-0006eI-3s for tls@ietf.org; Thu, 09 Oct 2014 06:27:22 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 9 Oct 2014 07:27:20 -0400 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.234 X-Exim-ID: 1XcBsQ-0006eI-3s X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [173.73.121.234]:63916 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TQlnkxKHf7rOwGT9E72W9B_wlQI Subject: [TLS] draft agenda TLS WG interim 21-22 October X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 11:27:26 -0000 All, Here=92s a draft agenda, which can also be found @ the interim meeting = site: http://www.ietf.org/meeting/interim/proceedings.html Please let me know if you have anything to add: Day 1: October 21 (mostly TLS maintenance) 0900 - 0930 Get Settled, Administrivia, Agenda (30 min) 0930 - 1030 Session Hash for 1.2 1030 - 1100 Break 1100 - 1145 Downgrade SCSV 1145 - 1300 Lunch 1300 - 1345 Deprecating RC4: 2119 levels (Andrei on Phone) 1345 - 1430 Negotiated Finite Field Diffie-Hellman Ephemeral = Parameters for TLS (what's left to decide?) 1500 - 1530 Break 1530 - 1700 TLS 1.3 Named Group negotiation (follow up from YYZ) [break] 1800 - late Dinner Day 2: October 22 (mostly TLS 1.3) 0900 - 0915 Get Settled, Administrivia, Agenda (15 min) 0915 - 1000 Session-Hash for 1.3 1000 - 1030 Resumption (do we still need it) 1030 - 1100 Break 1100 - 1200 Key Refresh/Refactoring Client Auth (I) 1200 - 1315 Lunch 1315 - 1415 Key Refresh/Refactoring Client Auth (II) 1415 - 1500 0-RTT (I) 1500 - 1530 Break 1530 - 1630 0-RTT (II) 1630 - 1700 Intentionally left open. J&S= From nobody Thu Oct 9 04:30:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B02B1ACD89 for ; Thu, 9 Oct 2014 04:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAkpsIsG879X for ; Thu, 9 Oct 2014 04:30:50 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.124.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893E31ACD78 for ; Thu, 9 Oct 2014 04:30:50 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 21550B5E028E6; Thu, 9 Oct 2014 06:30:50 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 1295DB5E0289F for ; Thu, 9 Oct 2014 06:30:50 -0500 (CDT) Received: from [173.73.121.234] (port=63922 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XcBvl-00039r-FU for tls@ietf.org; Thu, 09 Oct 2014 06:30:49 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Thu, 9 Oct 2014 07:30:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2ACC7CB4-4187-4234-9E23-A249F36CB524@ieca.com> References: <20140904192221.9668.41197.idtracker@ietfa.amsl.com> To: "TLS@ietf.org (tls@ietf.org)" X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.234 X-Exim-ID: 1XcBvl-00039r-FU X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [173.73.121.234]:63922 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vl6vLx6mrhnmdMJ0_ASN4DqPNps Subject: [TLS] reminder: Re: TLS WG Interim Meeting, 21-22 October 2014 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 11:30:56 -0000 Just a reminder: On Sep 04, 2014, at 17:40, Sean Turner wrote: > Registration: If you did not fill out the doodle poll please send the = TLS chairs an email at tls-chairs@tools.ietf.org. If you did fill out = the doodle poll and are not planning to attend please send the TLS = chairs an email letting us know. We need a list of attendees for admin = reasons. Thanks, spt= From nobody Thu Oct 9 04:37:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1793E1A8840 for ; Wed, 8 Oct 2014 18:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V1tO6jfev1d for ; Wed, 8 Oct 2014 18:07:14 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BA51A883F for ; Wed, 8 Oct 2014 18:07:13 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id l4so207432lbv.10 for ; Wed, 08 Oct 2014 18:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=/uRR4IxwH8uVZVnvhnN5AnMVx/96/H1JYzSf+70I4lg=; b=Sf0GJ7yyWaggmFcal5nvNmRSjKx+ryG4O9YnrV2RUz64XI31nWxKjSywDaORC95dsn okxcaypfBZ6d+5BTcLzQ9tvwDfjcKxzsXkJ7dpNYiJ2faBVBok/1bQTvHD5q7EUQQiqO Av6EywQqw3cvhZW61u7Nm/QjaCTueuk3rp1eqNjRzTeC6UNO/n624A30wqrYC2V3A85T rgKV5BYRZZw5A2t4SKd3XD4QMVsfafZaW9hftEpOGjExyL2DQhqkTjbCkkhVgHWc9BpX z6CQ/SbUElDBIyl/uafwzOvV1YPrzkpWvAdE3AL1vqs/ilzujcquFG0nqxLanxPEbvOG 42uw== MIME-Version: 1.0 X-Received: by 10.152.87.65 with SMTP id v1mr15236543laz.83.1412816831977; Wed, 08 Oct 2014 18:07:11 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Wed, 8 Oct 2014 18:07:11 -0700 (PDT) Date: Wed, 8 Oct 2014 21:07:11 -0400 X-Google-Sender-Auth: t43wIWdTzhYnq7fSocB2y0pF-yw Message-ID: From: Phillip Hallam-Baker To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vxCgoYHjI2bVNYJup7NxpA4I6N8 X-Mailman-Approved-At: Thu, 09 Oct 2014 04:37:54 -0700 Subject: [TLS] New directions in certificate status X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 01:07:16 -0000 Please note: http://datatracker.ietf.org/doc/draft-hallambaker-compressedcrlset/ Also note the pending IPR disclosure. In brief Rob Stradling and myself have come up with a radically new approach to certificate status that is vastly more efficient than any previous proposal that provides finer grain certificate status than the certificate validity interval. While compressing hash tables might appear to be a fools errand, it turns out that if the problem is correctly understood, CRLs actually compress astonishingly well. It is actually possible to represent the status of every one of the half million revoked certificates in the WebPKI using fewer bytes than the heavily edited Google CRLSet. There is still a powerful case for short lived certificates. But the minimum feasible expiry interval for short lived certs is 48 hours. Using a compressed CRL in combination with short lived certs would allow the vulnerability window to be reduced to minutes. We are of course aware that deployment will require a licensing regime that meets the need of all parties including competing CAs, open source software providers, etc. However lacking an existing licensing regime for the rights holder (if indeed any are granted), I thought it best to bring this to people's attention first. The nature of the invention is such that not applying for a patent would open the possibility that someone else might make a claim as has happened to me on numerous other occasions. In the past five years over $50 million has been spent on defending against such patent claims. From nobody Thu Oct 9 08:07:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895F11A1B13 for ; Thu, 9 Oct 2014 08:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jTV-_GbylbB for ; Thu, 9 Oct 2014 08:07:06 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E02D1A1AFE for ; Thu, 9 Oct 2014 08:07:03 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id v1so794971yhn.21 for ; Thu, 09 Oct 2014 08:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kGkjMSBa3hXz+oyE3SyUQscB7ARzLbFIP4SGbxKyz6g=; b=nblXpNSvNatJD1Bic8jfPJQ/GwiPhPe8yVfSzwW6qFqmu+of5vmB08LoXM/G1qpmD5 eo6TlbmUJvd75p2SzkAx1wAEeTR1/UvnkgyG0NKphxzsnZ79HAqcWnw7ERgW1037gcxu VV7PwcA8Brng9LQqiRZspUmz5cMk9zISpQT2gsIAIy4Muc7x3w+taPpE6jRsI3X1uWMi yUH0QOJTESnWBVMyrjZCmP2Gbjm1/XvsRUS1suPSgxJvmASLa5iD37HPCud+HG/Tw7g+ QIzoSrQY/tfY+CVvanzhLdX0MWmwUlNu+L6t5mlTaVqnQoB/QxjbXgAxoId5bxtH8wpp JOLQ== MIME-Version: 1.0 X-Received: by 10.236.51.201 with SMTP id b49mr26483027yhc.33.1412867222245; Thu, 09 Oct 2014 08:07:02 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Thu, 9 Oct 2014 08:07:02 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Oct 2014 08:07:02 -0700 Message-ID: From: Watson Ladd To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nw3ZryEcXqFMAFiYHw055vADSaI Cc: "tls@ietf.org" Subject: Re: [TLS] New directions in certificate status X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 15:07:08 -0000 On Wed, Oct 8, 2014 at 6:07 PM, Phillip Hallam-Baker wrote: > Please note: > > http://datatracker.ietf.org/doc/draft-hallambaker-compressedcrlset/ > Also note the pending IPR disclosure. > > In brief Rob Stradling and myself have come up with a radically new > approach to certificate status that is vastly more efficient than any > previous proposal that provides finer grain certificate status than > the certificate validity interval. Good idea. Unfortunately the draft is incomprehensible: key details are missing. If understand this correctly, the idea is to use a crit-bit tree to encode the certificate serial numbers, by removing common prefixes. There are a lot of finicky details to specify, but this should help. What would be nice is some hard numbers on how much it helps. > > While compressing hash tables might appear to be a fools errand, it > turns out that if the problem is correctly understood, CRLs actually > compress astonishingly well. It is actually possible to represent the > status of every one of the half million revoked certificates in the > WebPKI using fewer bytes than the heavily edited Google CRLSet. > > There is still a powerful case for short lived certificates. But the > minimum feasible expiry interval for short lived certs is 48 hours. > Using a compressed CRL in combination with short lived certs would > allow the vulnerability window to be reduced to minutes. > > > We are of course aware that deployment will require a licensing regime > that meets the need of all parties including competing CAs, open > source software providers, etc. However lacking an existing licensing > regime for the rights holder (if indeed any are granted), I thought it > best to bring this to people's attention first. Are you saying FRAND or something else? > > The nature of the invention is such that not applying for a patent > would open the possibility that someone else might make a claim as has > happened to me on numerous other occasions. In the past five years > over $50 million has been spent on defending against such patent > claims. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Oct 9 10:10:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2A71AD3C2 for ; Thu, 9 Oct 2014 10:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_cT_PyvNaRY for ; Thu, 9 Oct 2014 10:10:00 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B0771AD3C4 for ; Thu, 9 Oct 2014 10:06:05 -0700 (PDT) Received: from BY2FFO11FD023.protection.gbl (10.1.14.33) by BY2FFO11HUB006.protection.gbl (10.1.14.164) with Microsoft SMTP Server (TLS) id 15.0.1039.16; Thu, 9 Oct 2014 17:06:02 +0000 Received: from mx02.five9.com (198.105.204.3) by BY2FFO11FD023.mail.protection.outlook.com (10.1.15.212) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Thu, 9 Oct 2014 17:06:02 +0000 Received: from MB03.five9.com (10.7.8.143) by mx02.five9.com (10.7.15.112) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Oct 2014 10:05:10 -0700 Received: from MB02.five9.com ([fe80::ede6:8312:5207:4046]) by mb03.five9.com ([fe80::4d18:3a9c:2936:eea8%16]) with mapi id 14.03.0158.001; Thu, 9 Oct 2014 10:06:01 -0700 From: Ronald del Rosario To: "mrex@sap.com" , Hubert Kario Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt Thread-Index: AQHP4aKTa2Q4hqaWq0uxWUf2L1RqIJwj+Q2AgAQKQ4A= Date: Thu, 9 Oct 2014 17:06:00 +0000 Message-ID: References: <1381566393.7039054.1412626641999.JavaMail.zimbra@redhat.com> <20141006202411.5FB491AEB1@ld9781.wdf.sap.corp> In-Reply-To: <20141006202411.5FB491AEB1@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.7.8.130] Content-Type: multipart/related; boundary="_004_D05C0DA3159B2rrosariofive9com_"; type="multipart/alternative" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:198.105.204.3; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(24454002)(377454003)(199003)(189002)(561944003)(77096002)(44976005)(83506001)(53416004)(92726001)(67866002)(86362001)(16236675004)(46102003)(19580405001)(50986999)(84326002)(64706001)(2656002)(20776003)(99936001)(92566001)(87936001)(21056001)(15975445006)(76176999)(66926002)(54356999)(575784001)(17760045003)(512944002)(19580395003)(85852003)(80022003)(15202345003)(15974865002)(19627595001)(19617315012)(76482002)(31966008)(2501002)(18206015026)(230783001)(71186001)(85306004)(95666004)(106466001)(120916001)(106116001)(36756003)(6806004)(99396003)(107046002)(4396001)(85436002)(24704002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB006; H:mx02.five9.com; FPR:; MLV:sfv; PTR:mx02.five9.com; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB006; X-Forefront-PRVS: 0359162B6D Received-SPF: Pass (protection.outlook.com: domain of five9.com designates 198.105.204.3 as permitted sender) receiver=protection.outlook.com; client-ip=198.105.204.3; helo=mx02.five9.com; Authentication-Results: spf=pass (sender IP is 198.105.204.3) smtp.mailfrom=rrosario@five9.com; X-OriginatorOrg: five9.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vBgsdKB9oSkZBSUtpPrqVtXafcw Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 17:10:03 -0000 --_004_D05C0DA3159B2rrosariofive9com_ Content-Type: multipart/alternative; boundary="_000_D05C0DA3159B2rrosariofive9com_" --_000_D05C0DA3159B2rrosariofive9com_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable "I'm not sure how representative that cloudflare statistic is. But if this is anywhere near the real numbers, that the current "MUST NOT" for server would be clear fear-mongering rather than providing the target audience a sensible information about the trade-off and realistic perspective on the insignificance of the perceived threat. -Martin=94 +1 I live in a browser-integration world (CRM, Softphone clients, etc.) and di= sabling support for RC4 will be a burden since we still have a big percenta= ge of customers using WindowsXP/IE6 (Obsolete clients) due to legacy custom= integrations they are running. I feel that making RC4 a "MUST NOT=94 and ending up as an IETF Standard is = too much fear-mongering. Best, Ron F. del Rosario Information Security Officer [cid:D8C7FEEC-B79B-4830-9898-1599B9F2269E] Five9, Inc. Cloud Contact Center Software 4000 Executive Pkwy, Ste 400 San Ramon, CA 94583 www.Five9.com From: Martin Rex > Reply-To: "mrex@sap.com" > Date: Monday, October 6, 2014 at 1:24 PM To: Hubert Kario > Cc: "tls@ietf.org" > Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt Hubert Kario wrote: My issue is with the IMHO bogus "MUST NOT" for servers. Servers have no control over the client behaviour, and the current proposal calls for an unconditional hard failure (equals to "come back in clear text") rather than interoperating with an RC4-based TLS cipher suites with installed base clients. thing is that only very specific clients do advertise only RC4, far less than there are RC4 only servers. Cloudflare saw on the order of 0.000002% of connections end up with RC4: http://blog.cloudflare.com/the-web-is-world-wide-or-who-still-needs-rc4/ All from long obsolete clients. Previously they saw on the order of 0.0009%: http://blog.cloudflare.com/killing-rc4-the-long-goodbye/ I'm not sure how representative that cloudflare statistic is. But if this is anywhere near the real numbers, that the current "MUST NOT" for server would be clear fear-mongering rather than providing the target audience a sensible information about the trade-off and realistic perspective on the insignificance of the perceived threat. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . --_000_D05C0DA3159B2rrosariofive9com_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0DE8FB5CE29BDD49AA2B24C89919F104@five9.com> Content-Transfer-Encoding: quoted-printable
"I'm not sure how representative that cloudflare statistic is.=

But if this is anywhere near the real numbers, that the current=
"MUST NOT" for server would be clear fear-mongering rathe= r than
providing the target audience a sensible information about the<= /div>
trade-off and realistic perspective on the insignificance of
the perceived threat.

-Martin=94

+1 

I live in a browser-integration world (CRM, Softphone clients, etc.) a= nd disabling support for RC4 will be a burden since we still have a big per= centage of customers using WindowsXP/IE6 (Obsolete clients) due to legacy custom integrations they are running.

I feel that making RC4 a "MUST NOT=94 and ending up as an IETF St= andard is too much fear-mongering.

Best,

= Ron F. de= l Rosario

I= nformation Security Officer




Five9, Inc. 
Cloud Contact Center Software 
4000 Executive Pkwy, Ste 400 San Ramon, CA 94583 


From: Martin Rex <mrex@sap.com>
Reply-To: "mrex@sap.com" <mre= x@sap.com>
Date: Monday, October 6, 2014 at 1:= 24 PM
To: Hubert Kario <hkario@redhat.com>
Cc: "tls@ietf.org" <tls@ietf.= org>
Subject: Re: [TLS] I-D Action: draf= t-ietf-tls-prohibiting-rc4-01.txt

Hubert Kario wrote:

My issue is with the IMHO bogus "MUST NOT" for servers.
Servers have no control over the client behaviour, and the current
proposal calls for an unconditional hard failure (equals to
"come back in clear text") rather than interoperating with a= n
RC4-based TLS cipher suites with installed base clients.

thing is that only very specific clients do advertise only RC4,
far less than there are RC4 only servers. Cloudflare saw on the
order of 0.000002% of connections end up with RC4:
All from long obsolete clients.
Previously they saw on the order of 0.0009%:


I'm not sure how representative that cloudflare statistic is.

But if this is anywhere near the real numbers, that the current
"MUST NOT" for server would be clear fear-mongering rather t= han
providing the target audience a sensible information about the
trade-off and realistic perspective on the insignificance of
the perceived threat.

-Martin

_______________________________________________
TLS mailing list



CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are= not the intended recipient, please notify the sender immediately, destroy = the original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the information in any medium. Copyright= in this e-mail and any attachments belongs to Five9 and/or its affiliated = entities.
--_000_D05C0DA3159B2rrosariofive9com_-- --_004_D05C0DA3159B2rrosariofive9com_ Content-Type: image/png; name="063218CA-78F5-4C87-B33F-1AF1081079A5[5].png" Content-Description: 063218CA-78F5-4C87-B33F-1AF1081079A5[5].png Content-Disposition: inline; filename="063218CA-78F5-4C87-B33F-1AF1081079A5[5].png"; size=4841; creation-date="Thu, 09 Oct 2014 17:06:00 GMT"; modification-date="Thu, 09 Oct 2014 17:06:00 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEsAAAAoCAYAAAC2LgceAAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAAIY0lEQVRo BdVazXITRxCenhWB3JwniLhhKgf5mAIT+QkwDwCWnsDC5G77ntjyE2gND4D8BF4wVI44VSnMDfEE 0Q0StNv5enZnNftnW2KFyVStpqenZ6ant7une1bEzOpbLLd/P1lniu4zU4tItfI8guuxUhxopV+w DodnvfYoT1N3m74lYa30g6VPke5BEJuk1NJsm2Vfad5dpNC+GWGJJkXEg9mFlBUpBN3/Xke7b3pt aF69Rdc73XyzLe+9GDDx8wsFRRTE5le9DubofQz18U/9oGC61aMu13PlmiWCUoo65eyyT6yPrnth kNcUEcYk0hsQzjrGNvPjRagNHa391Wuf5vvmbV+psKoFxf4NzY/zAqra5PLeSYcV7+c1UwRGOlqp y49dmbBu753AkfO+KwCzuSh6cPZrO3Dxl4HN4cDec8Xcdulx2J++e3JvxcXNC1+JsJb7QVNF+r3L dF1mU6Gtu2db93bc9eaBr8TBc0QZjRLG6/IvZ1u/dEWbXGHgRWyK5rm4eeCvqlnC8Gc44zDSb3LM 1vLm7ZyiuYw1XB8GgfUpio4sjddQ41md/8KEFQeY3jqr6D5Ou7bLuGU4qUcwkZs53Bc3l/de7mCS 7Ysmgt8cktJHN5AFXHSg1G6GIiRh9KPxSRJk0vo5glLoP7hoQ/P039BR/zLjhD+kTQPhNxFw5bBa NUtiH5jYc6zWrFwx14FN/XDRG80NuXTz1t4LBLoijMsX8XcNL+qWmWhtmiWxDoLEY7DVPIe1Efrk MUUYW5SgZAEI6s94JWlQ4D7wYeO0zwEkaZd9yH4ctAEbecQ87eXfgrbSWvK6TBGGCD5BRXyYj51i LfRamQF1N3TkU+idvn2yOiybOuaBNjnnKmK3wQPkq2N37Bebofgosfd4gSlLxnEiCq8rep7OXD8U n56EDCBrsvKy3ZDmizXrY0SiUUvZLbD/DvFOFvfttpIX+uDW3ktJmXqWU9nXJNQDtE0GQOruox3b OUvNJ4c7ifkdZ8exL4FhFnd1LTeEIdLpS8U93inyxoO85pdnANQ921r1Sd15CG2buYz41dObJROP cLqtLNJpz8Kp9aUY06wah833323de+z2L++fHOdyTBMLznsaGocpjtFdBEfOQi7dsmtcrmVOM33h 6YwTU/Xilz6d16MwIzz0NOVycj5hER/JWxObtkvgDY1FVW37KmvjsHM3GufzQx03IJUYSw4od4x8 Dyg6eKJdl6gUnngjJSMjldLiJBmV0l4FMqJt90UKC+Dv8XUd+uIiyswTL1uS7b51IZICIbJPLUc+ nBSEJY77Mvujte6SmkyClDZqjNXWqqLVh+0UJ8CkMeI/BqMMLmnQz92makyabh+fPAvctpmPaQO4 Jp4WNjDC1seAj9Q1z+fjgcCZksRNKU4E9XZrtW8REvNB+9bcZFuE+0/otUEzFDrJFfHxZCCwFAlW 5zNDGT2ZtBQTHGHyUBhfuzBtpzjp88JtIS8t0mfHm1rFc4BYBEl3H8XzK9UBqo1nCT2tBN5Xn8P3 oOmhnRYJNF2tYrgHV1CWUE5BEzBbBGp8B5C5TbEaZttSzy8sdxYXZnXoNgF3jBbmkAluPYPmOKmm O90WhPwGfe1Mf7GxBNQ+BJZqQDiZ+lEhJ6LT4jCLoQ8Wukxdu7D49VMfC48zi/8bZoUinTFONmvL WH3nDY0QKTwG0u1LaPgUwChpuFUnr2G2E/FUy8LFmn8s4qoxBZ9lVL+aHrqqDhOBnEflo7OXEhBv AhacW+67DcDG/yRakhWUHDoN3bf+KfZjYrLGJO002xC037q/cfopsihQQOhy3583RTFXGFZnSinQ 9JCSYDZveAVhYURbhlUWTS8q+2xH6B3AjKbCwqbEB1lHH2uP+YRlRyiFMcbhe8Y/TfGsuvzq0J8i 8L5wCGCONfgsMdVm0ocDJ+rB1+wgqAzcoJIRRiA0WFJIrG9A6z9FcimpJbXJFh0GFmGcPcHjJUVu SGo3Q5nbCIXjU8UuphpRJ4WLZhmYMV7BXIMqLTZaxtPQxczNciuLEoa7ps7+bMtHEpxwf4PD0nzW TX0krsoMJxWUaVaGZu6Gx4cqciJ85g3MtZPMl2VkeijkfUh8IlYxQQxTcfUjNksJDZAU99HjaHfV JBAdtI3wPwlLkZhgx7allvv7grCQ87mru/Qzwfzy2RD+Z4RBzWRg05xy38FBU8YEx472tBJaW8lY eSpKNauS78FXfYgUFwLU/GQaadpb5184n4pfn0byAhZihikzRIcpLACFm/AznSzOuYPn3CmaIZy9 IU4dfxK5KUEp9McXv1OYBTeorvM30b2ijktHLOPxuc5F1g5PtJ8LStfBNLTH0QihsUXjGpinKQbQ 0MKcwC1tWc08zqOT4LIv+OQ2ISUx5kdhN0UIoL0meNy1OAg6vS1dqLDEadOdR0PH7JYgKAgrKTgE 7AlpMJEGbSbily/XQ349OLVD3LqQWoWNkdvvwhI+QAhtF5c3P+k77zJgsWYoq2s+kKq0yCHglEQo IwclpntcEAoITDyWSZWQWmmFl1EscgshvivTkzO/TF9FY6GaJWuamCjr6C0rIzkEbCOtibsmX0wR EACEQncfQrsoAFoE0sbTxOOWfpUGKvYQKsjJGZdS87Od59SL16x48aJ2Vfgic+uAQLTIM7WA6+Hp 4GnicQrSoGveroNIQWN+uX/WiPm5MVVKfAHwdYSFq5QCH0hfCrgEYUKJWGDjKhoH76trjTWbCjl4 VZf52TkbOG1K34glqKxxT4WofDo2knum8iIbgaPvKk1NQwHass25o0VgSGmGksLghNxAXzw2Jhoj kgzEH+bvv9w58M2wpSjnMyn0XZpZ4C/+bjjLYv932v8A3PTEbUKtr9sAAAAASUVORK5CYII= --_004_D05C0DA3159B2rrosariofive9com_-- From nobody Thu Oct 9 11:06:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838681AD4F5 for ; Thu, 9 Oct 2014 11:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P48aeqUcTUk3 for ; Thu, 9 Oct 2014 11:06:02 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE801AD4F2 for ; Thu, 9 Oct 2014 11:06:01 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so657901qcv.24 for ; Thu, 09 Oct 2014 11:06:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=e3jVcsie6KJDvI+rirR4gxEnwrBt7T8ifyBqcn7IF8g=; b=eP9fiXXd5Uj1cObxNLhCqdNGQ1iUPlOmavvW9gEMXlNPT8iD+8PzJWptP2t9of43if 6IkgQwintFIC8sy8JHJLT7tWxUj2hFcRSMgzYvgM3tjsTgTfNdw/jVCELv+I+aL9CseO +e+wSimEpDuV4rtUAADBMy5bU+RdjC46bFAfiMtuQMmRTVpqT1y2TvRQ0N1KaLxIkJ6q sm6Wg2BXA0Eiq4D3IkhhTlH2lRYxgmIn9TPYB0TEmEymF/jvjCvqJFoGLDnJCQMfZJyw WDAU6byWJbx/gG2h1u3GlSRyzARo/x/MzTeRO8qeerts+Um9PKmM9DqPUyK+ByQ/R38r v+Mw== X-Gm-Message-State: ALoCoQngu6ISNksucDCdb4uyFJ+CY5Ll/xHNkviAqmnZS4kjToDXQdnKZwJ4wSiDO/spfO9W+7Am X-Received: by 10.224.152.6 with SMTP id e6mr26226581qaw.34.1412877959761; Thu, 09 Oct 2014 11:05:59 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:e7:b5ce:17f5:560d:a3a7? ([2601:a:2a00:e7:b5ce:17f5:560d:a3a7]) by mx.google.com with ESMTPSA id g5sm2956069qaz.39.2014.10.09.11.05.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Oct 2014 11:05:59 -0700 (PDT) Message-ID: <5436CE97.8040107@nthpermutation.com> Date: Thu, 09 Oct 2014 14:06:15 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: tls@ietf.org References: <20141007193512.GA32644@LK-Perkele-VII> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090008060907040202080301" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2UVUnjat6ibtNTCdRzmpR5I1Yug Subject: Re: [TLS] Pull Request #82: Merge in ECC and Negotiated FF-DHE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 18:06:08 -0000 This is a multi-part message in MIME format. --------------090008060907040202080301 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 10/7/2014 5:45 PM, Eric Rescorla wrote: > > > On Tue, Oct 7, 2014 at 12:35 PM, Ilari Liusvaara > > wrote: > > On Tue, Oct 07, 2014 at 11:17:15AM -0700, Eric Rescorla wrote: > > Folks, > > > > I've just made Pull Request 82, which implements a number of > > the changes we discussed in Toronto, including: > > > > - Merge in support for ECC from RFC 4492. > > Might be a good idea to allow curve to specify a format for ECDHE. > This avoids trouble with "exotic" formats (useful for what is > expected for CFRG curves[1] and some other high-performance curves). > > > Yes, see the somewhat opaquely worded note here: > https://github.com/tlswg/tls13-spec/pull/82/files#diff-9d84740dcc569a0a5a359d0fba461a05R1968 Wouldn't it make sense not to overload this? Keep the current code point for X9.62 curve based public data and assign a new code point to anything non-X9.62 compliant? Or maybe we need to take a more "meta" look at representing EC cryptography given the discussions at the last CFRG - X9.62, Curve25519, Ed25519, Weiserstrass (mostly X9.62), twisted Edwards, etc. Even though these are all "elliptic curve", they can easily be as distinct - representation wise - as RSA is from EC X9.62. Mike > > The presently defined ECC curves can use X9.62 formats for ECDHE. > > Also, note that ClientKeyShare representations are unnegotiable > (at least for optimistic round), so one presumably needs to fix > the representation (X9.62 compressed?) even for existing groups). > > > IIRC, the points are self-describing as to whether they are compressed > or not, so the client has to choose, but he might guess wrong as > he does with the groups. I would actually prefer to fix the representation > if that's possible, but I figure that's a separable question. > > > > - Rename {Client,Server}KeyExchange to {Client,Server}KeyShare > > How does the server know to expect CKS? If ClientVersion is 3.4 > or higher and there is no first flight extension in ClientHello? > > > Yes. > > Due to how TLS handshake and underlying transport works, the > last message in flight can not be optional. And sending CKS as-is > would cause TLS 1.2 server to blow up. > > > Yes. You always must send it either in EarlyData or otherwise. And if > you don't know, it has to go in the extension for backwards compatibility. > > > > > - Add an explicit HelloRetryRequest to reject the client's > > ClientKeyShare. This was something we discussed and just makes > > things a lot clearer. > > Now you have duplicate ClientHello and parts of ServerHello, both > of which must be checked for constency. If you don't, you have a > security hole (especially if one restarts hash). > > I would rather not have such traps in the spec. > > And since one needs copies of CH and SH to check them, sending > them again is completely redundant. > > > Can you elaborate on your concern here? > > Also, omitting the superfluous CH and SH-parts will let one omit > the redundant key shares. > > > As I think I said previously, there was consensus to use this design > at the Denver interim in the name of consistency. All I've done here > is change the server's first ServerHello to a HelloRetryRequest, > which I believe is consistent with that decision. If the WG consensus > is to change this, I'll make the change. > > > Other notes: > > Named_groups is not noted to be mandatory. What happens if it > is missing? Fatal error? Optimistic CKS has all supported > groups? > > > My bad. This was supposed to be mandatory but it got lost in an > editorial pass. I will fix. > > The optimistic nature of CKS means that Supported Point Formats > can't really be applied to ECDHE key exchange, only to > signatures. > > > I don't believe this is true. Supported points is the list of points that > you will let the other side send, not that you can send. See: > > https://github.com/tlswg/tls13-spec/pull/82/files#diff-9d84740dcc569a0a5a359d0fba461a05R2394 > > So, what you are saying is "regardless of what formats I sent you, > send me X". Also, Supported Points can be used by the server > in the HelloRetryRequest to indicate if the client sent an inappropriate > point format. > > I recognize all this point negotiation is silly and as I said, I would be > fine if we just required one form. See issue: > > https://github.com/tlswg/tls13-spec/issues/80 > > > Also, in Supported Point Formats, if it does not apply to > ECDHE (due to the problem above), what does it apply to? > The only another points are in host key, which is inside > certificate, and thus one would have to drive certificate > choice off SPF. > > > Yes, 4492 requires this: > > "The server constructs an appropriate certificate chain and conveys it > to the client in the Certificate message. If the client has used a > Supported Elliptic Curves Extension, the public key in the server's > certificate MUST respect the client's choice of elliptic curves; in > particular, the public key MUST employ a named curve (not the same > curve as an explicit curve) unless the client has indicated support > for explicit curves of the appropriate type. If the client has used > a Supported Point Formats Extension, both the server's public key > point and (in the case of an explicit curve) the curve's base point > MUST respect the client's choice of point formats. (A server that > cannot satisfy these requirements MUST NOT choose an ECC cipher suite > in its ServerHello message.)" > > The stuff copied to section "Elliptic Curve Diffie-Hellman" > is likely totally inapporiate for CFRG curves. One idea > would be to encode the output point as it would be sent > on the wire in CKS/SKS. > > > I've filed the following issue to deal with this when those curves > pop out: > > https://github.com/tlswg/tls13-spec/issues/83 > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------090008060907040202080301 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 10/7/2014 5:45 PM, Eric Rescorla wrote:


On Tue, Oct 7, 2014 at 12:35 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
On Tue, Oct 07, 2014 at 11:17:15AM -0700, Eric Rescorla wrote:
> Folks,
>
> I've just made Pull Request 82, which implements a number of
> the changes we discussed in Toronto, including:
>
> - Merge in support for ECC from RFC 4492.

Might be a good idea to allow curve to specify a format for ECDHE.
This avoids trouble with "exotic" formats (useful for what is
expected for CFRG curves[1] and some other high-performance curves).

Yes, see the somewhat opaquely worded note here:

Wouldn't it make sense not to overload this?  Keep the current code point for X9.62 curve based public data and assign a new code point to anything non-X9.62 compliant?

Or maybe we need to take a more "meta" look at representing EC cryptography given the discussions at the last CFRG - X9.62, Curve25519, Ed25519, Weiserstrass (mostly X9.62), twisted Edwards, etc.  Even though these are all "elliptic curve", they can easily be as distinct - representation wise - as RSA is from EC X9.62.

Mike

 
The presently defined ECC curves can use X9.62 formats for ECDHE.

Also, note that ClientKeyShare representations are unnegotiable
(at least for optimistic round), so one presumably needs to fix
the representation (X9.62 compressed?) even for existing groups).

IIRC, the points are self-describing as to whether they are compressed
or not, so the client has to choose, but he might guess wrong as
he does with the groups. I would actually prefer to fix the representation
if that's possible, but I figure that's a separable question.


> - Rename {Client,Server}KeyExchange to {Client,Server}KeyShare

How does the server know to expect CKS? If ClientVersion is 3.4
or higher and there is no first flight extension in ClientHello?

Yes.

 
Due to how TLS handshake and underlying transport works, the
last message in flight can not be optional. And sending CKS as-is
would cause TLS 1.2 server to blow up.

Yes. You always must send it either in EarlyData or otherwise. And if
you don't know, it has to go in the extension for backwards compatibility.


 

> - Add an explicit HelloRetryRequest to reject the client's
>   ClientKeyShare. This was something we discussed and just makes
>   things a lot clearer.

Now you have duplicate ClientHello and parts of ServerHello, both
of which must be checked for constency. If you don't, you have a
security hole (especially if one restarts hash).

I would rather not have such traps in the spec.

And since one needs copies of CH and SH to check them, sending
them again is completely redundant.

Can you elaborate on your concern here?

 
Also, omitting the superfluous CH and SH-parts will let one omit
the redundant key shares.

As I think I said previously, there was consensus to use this design
at the Denver interim in the name of consistency. All I've done here
is change the server's first ServerHello to a HelloRetryRequest,
which I believe is consistent with that decision. If the WG consensus
is to change this, I'll make the change.


Other notes:

Named_groups is not noted to be mandatory. What happens if it
is missing? Fatal error? Optimistic CKS has all supported
groups?

My bad. This was supposed to be mandatory but it got lost in an
editorial pass. I will fix.

 
The optimistic nature of CKS means that Supported Point Formats
can't really be applied to ECDHE key exchange, only to
signatures.

I don't believe this is true. Supported points is the list of points that
you will let the other side send, not that you can send. See:


So, what you are saying is "regardless of what formats I sent you,
send me X". Also, Supported Points can be used by the server
in the HelloRetryRequest to indicate if the client sent an inappropriate
point format.

I recognize all this point negotiation is silly and as I said, I would be
fine if we just required one form. See issue:



Also, in Supported Point Formats, if it does not apply to
ECDHE (due to the problem above), what does it apply to?
The only another points are in host key, which is inside
certificate, and thus one would have to drive certificate
choice off SPF.

Yes, 4492 requires this:

" The server constructs an appropriate certificate chain and conveys it
   to the client in the Certificate message.  If the client has used a
   Supported Elliptic Curves Extension, the public key in the server's
   certificate MUST respect the client's choice of elliptic curves; in
   particular, the public key MUST employ a named curve (not the same
   curve as an explicit curve) unless the client has indicated support
   for explicit curves of the appropriate type.  If the client has used
   a Supported Point Formats Extension, both the server's public key
   point and (in the case of an explicit curve) the curve's base point
   MUST respect the client's choice of point formats.  (A server that
   cannot satisfy these requirements MUST NOT choose an ECC cipher suite
   in its ServerHello message.)"

            

            
 

            
The
              stuff copied to section "Elliptic Curve Diffie-Hellman"

              is likely totally inapporiate for CFRG curves. One idea

              would be to encode the output point as it would be sent

              on the wire in CKS/SKS.

            


            

            
I've filed the following issue to deal with this when
              those curves

            
pop out:

            


            

            
            
 

            
-Ekr

          

        

      

      

      

      

      
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


    

    

  


--------------090008060907040202080301--


From nobody Thu Oct  9 11:37:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A767C1A01B0 for ; Thu,  9 Oct 2014 11:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bFO1rL65z_W for ; Thu,  9 Oct 2014 11:37:22 -0700 (PDT)
Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B5D1A028B for ; Thu,  9 Oct 2014 11:37:21 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id z12so2046319wgg.25 for ; Thu, 09 Oct 2014 11:37:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QZ6ntJPkYkxph7nKTywB9/+lU2XhMN2ISJ+exm+6s4E=; b=H8kNgV3Roju2snyQtF91uPmSd0itxgWAtfQMgJb5V7mhzrhfxUTaTZsMdxQYF0NIOm qIyppxB6mS7fXb+zQaS4WZbcb4TLWUs5q3TsSLObru1I6oMHN1Wx3dolOooWFJkfLlEH bNKnaQaStKrJvsIksNfaOZvNjWjAVTtdmrXeYnvXDDdw7ekjtGATEPpzPl619fbF9obH y3xXQnoM0zAr5NToosZ7uGyPeVk0bo86f/klPmtsIqmemCUpQScvcOJVaiWqJQjQNH9l GxrCqYFceO2CkFKNjhGdTXFEtxTF92BKH4ABKJ5SlAX5FdgUpbZXFTKNYA8rijri0o9q I/Pg==
X-Gm-Message-State: ALoCoQmAyJ0RAk03wkAj7ohWvTqxRWGFycGBmHpeH/Ui6e/q/S06K3t7+NobJQgl4yI//2YGo6k+
X-Received: by 10.194.62.166 with SMTP id z6mr20056238wjr.44.1412879840395; Thu, 09 Oct 2014 11:37:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.130.130 with HTTP; Thu, 9 Oct 2014 11:36:40 -0700 (PDT)
In-Reply-To: <5436CE97.8040107@nthpermutation.com>
References:  <20141007193512.GA32644@LK-Perkele-VII>  <5436CE97.8040107@nthpermutation.com>
From: Eric Rescorla 
Date: Thu, 9 Oct 2014 11:36:40 -0700
Message-ID: 
To: Michael StJohns 
Content-Type: multipart/alternative; boundary=047d7b86e1ecff735b050501b853
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/miaVmJPkuX4xbTk1VUMbkaoBJZQ
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Pull Request #82: Merge in ECC and Negotiated FF-DHE
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 18:37:23 -0000

--047d7b86e1ecff735b050501b853
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 9, 2014 at 11:06 AM, Michael StJohns 
wrote:

>  On 10/7/2014 5:45 PM, Eric Rescorla wrote:
>
>
>
> On Tue, Oct 7, 2014 at 12:35 PM, Ilari Liusvaara <
> ilari.liusvaara@elisanet.fi> wrote:
>
>> On Tue, Oct 07, 2014 at 11:17:15AM -0700, Eric Rescorla wrote:
>> > Folks,
>> >
>> > I've just made Pull Request 82, which implements a number of
>> > the changes we discussed in Toronto, including:
>> >
>> > - Merge in support for ECC from RFC 4492.
>>
>> Might be a good idea to allow curve to specify a format for ECDHE.
>> This avoids trouble with "exotic" formats (useful for what is
>> expected for CFRG curves[1] and some other high-performance curves).
>>
>
>  Yes, see the somewhat opaquely worded note here:
>
> https://github.com/tlswg/tls13-spec/pull/82/files#diff-9d84740dcc569a0a5a359d0fba461a05R1968
>
>
> Wouldn't it make sense not to overload this?  Keep the current code point
> for X9.62 curve based public data and assign a new code point to anything
> non-X9.62 compliant?
>

Which code point are you referring to? Each curve will have its own code
point
in any case.

In any case, the intent with the current draft is simply to cover the
current
X9.62 compatible forms and then deal with whatever the CFRG comes out
with once that's finalized.

-Ekr

--047d7b86e1ecff735b050501b853
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 9, 2014 at 11:06 AM, Michael StJohns <=
msj@nthpermutat=
ion.com> wrote:

 =20
   =20
 =20
  

    
On 10/7/2014 5:45 PM, Eric Rescorla
      wrote:

    

    

      


        


          
On Tue, Oct 7, 2014 at 12:35 PM,
            Ilari Liusvaara <ilari.liusvaara@elisanet.fi>=

            wrote:

            
On
                Tue, Oct 07, 2014 at 11:17:15AM -0700, Eric Rescorla
                wrote:

                > Folks,

                >

                > I've just made Pull Request 82, which implements a
                number of

                > the changes we discussed in Toronto, including:

                >

                > - Merge in support for ECC from RFC 4492.

                

              Might be a good idea to allow curve to specify a
              format for ECDHE.

              This avoids trouble with "exotic" formats (useful f=
or what
              is

              expected for CFRG curves[1] and some other
              high-performance curves).

            

            


            

            
Yes, see the somewhat opaquely worded note here:

            
          

        

      

    

    

    Wouldn't it make sense not to overload this?=C2=A0 Keep the current=
 code
    point for X9.62 curve based public data and assign a new code point
    to anything non-X9.62 compliant?

<=
div>Which code point are you referring to? Each curve will have its own cod=
e point
in any case.

In any case, the in=
tent with the current draft is simply to cover the current
X9.62 =
compatible forms and then deal with whatever the CFRG comes out
w=
ith once that's finalized.

-Ekr
=C2=
=A0


--047d7b86e1ecff735b050501b853--


From nobody Thu Oct  9 12:26:31 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEC61A1AC7 for ; Thu,  9 Oct 2014 12:26:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vge_H5TOQt3 for ; Thu,  9 Oct 2014 12:26:27 -0700 (PDT)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE851A1AB7 for ; Thu,  9 Oct 2014 12:26:27 -0700 (PDT)
Received: by mail-qc0-f176.google.com with SMTP id r5so804421qcx.35 for ; Thu, 09 Oct 2014 12:26:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=uVUq66MYozC9M3ShcB24t3KHSquD1nI1cpmvH/HVnck=; b=NcoZhOpG+YqU5eeHakdpqflwtglU+oQ4CNFFeOo0/FZSZ7ANIp547w/hnqU1kR9YbO vACwlnyccT8GW2/s3rzrrZM5yUuvPmXrkwvqr7Nehwnbzqk+H11CbrtjCJtrOem6TwWu AOu1dwg2bbwFTRpr+pdvVQjMo58+5wz9+NL9cRChpW1k2sxUvDJeQ63/QBxFjsePzzUM nr+P8yuwAusr8vHB7Jg7hwPDuntSNy4qoWr7AaYodS0wk1jXWCV2XBJ01ZsZJPzASlH/ J7Bogutt5lgsPS9V5GvZMWhdI1DU2m9MI380VoANw5pdByZeI6q1UAxHhfUccB2JK6e+ f4fQ==
X-Gm-Message-State: ALoCoQmXsXjI+qG89hg6x1BL5mZm+DnndTTvCP8dyVSRELcoSpXXw93YszsaTz1JMsmc+4kSau3w
X-Received: by 10.224.130.130 with SMTP id t2mr581632qas.2.1412882786431; Thu, 09 Oct 2014 12:26:26 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:e7:b5ce:17f5:560d:a3a7? ([2601:a:2a00:e7:b5ce:17f5:560d:a3a7]) by mx.google.com with ESMTPSA id p45sm3119008qgd.49.2014.10.09.12.26.25 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Oct 2014 12:26:26 -0700 (PDT)
Message-ID: <5436E171.3070007@nthpermutation.com>
Date: Thu, 09 Oct 2014 15:26:41 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Eric Rescorla 
References:  <20141007193512.GA32644@LK-Perkele-VII>  <5436CE97.8040107@nthpermutation.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080704000908050101020600"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/o5oRnwvOITfDpwSemXOBsRCYw1I
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Pull Request #82: Merge in ECC and Negotiated FF-DHE
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 19:26:29 -0000

This is a multi-part message in MIME format.
--------------080704000908050101020600
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10/9/2014 2:36 PM, Eric Rescorla wrote:
>
>
> On Thu, Oct 9, 2014 at 11:06 AM, Michael StJohns 
> > wrote:
>
>     On 10/7/2014 5:45 PM, Eric Rescorla wrote:
>>
>>
>>     On Tue, Oct 7, 2014 at 12:35 PM, Ilari Liusvaara
>>     >     > wrote:
>>
>>         On Tue, Oct 07, 2014 at 11:17:15AM -0700, Eric Rescorla wrote:
>>         > Folks,
>>         >
>>         > I've just made Pull Request 82, which implements a number of
>>         > the changes we discussed in Toronto, including:
>>         >
>>         > - Merge in support for ECC from RFC 4492.
>>
>>         Might be a good idea to allow curve to specify a format for
>>         ECDHE.
>>         This avoids trouble with "exotic" formats (useful for what is
>>         expected for CFRG curves[1] and some other high-performance
>>         curves).
>>
>>
>>     Yes, see the somewhat opaquely worded note here:
>>     https://github.com/tlswg/tls13-spec/pull/82/files#diff-9d84740dcc569a0a5a359d0fba461a05R1968
>
>     Wouldn't it make sense not to overload this? Keep the current code
>     point for X9.62 curve based public data and assign a new code
>     point to anything non-X9.62 compliant?
>
>
> Which code point are you referring to? Each curve will have its own 
> code point
> in any case.

Sorry for my lack of clarity. "dhe-param" refers to X9.42 diffie-hellman 
public data.  "ecdhe-param" currently refers to X9.62 EC DH public 
data.   In some ways you could have had just the single "dhe-param" and 
use the type of algorithm to differentiate.

select (algorithm) {
     dh:
         opaque dh_Y<1..2^16-1>; // positive big endian integer - could 
be encoded that way
     ec962:
         opaque point<1..2^8-1>; // x9.62 formatted point, odd number of 
bytes, first byte is compression type
     curve25519:
         opaque publicKey <255>; // don't beat me up on size; little 
endian integer on curve25519
// other formats to come
}


So what I'm suggesting is that instead of changing the meaning/format of 
the "point" field in "ecdhe-param" to handle things like curve25519 or 
twisted edwards curves, to instead assign "ec25519dhe-param" or 
"tedhe-param" when and if the CFRG gets around to blessing them.

The math is different, the proposed formats are different etc.

Otherwise, you might want to signal the possibility that this isn't just 
an X9.62 point as:

select (curvetype) { // implicit
      x962:
          opaque point <1..2^8-1>;
// more curve types to come.
}

which may have been Ilari's point.


>
> In any case, the intent with the current draft is simply to cover the 
> current
> X9.62 compatible forms and then deal with whatever the CFRG comes out
> with once that's finalized.

Yup.  But always dealing with possible backwards compatibility.   If 
your intention is to overload ecdhe_param for the new curves, then it 
would be useful to provide the right encoding/implementation hints.  If 
you're going to allocate new code points for each parameter type, then 
there's nothing that needs changes right now.



BTW -you should probably change "ecdh_Y" to "ecdh_XY" in this line:
> The opaque value conveys the Elliptic +Curve Diffie-Hellman public 
> value (ecdh_Y)

Mike


>
> -Ekr


--------------080704000908050101020600
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/9/2014 2:36 PM, Eric Rescorla
      wrote:

    

    

      


        


          
On Thu, Oct 9, 2014 at 11:06 AM,
            Michael StJohns <msj@nthpermutation.com>
            wrote:

            

              

                  
On 10/7/2014 5:45 PM, Eric Rescorla wrote:

                  

                  

                    


                      


                        
On Tue, Oct 7, 2014 at
                          12:35 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
                          wrote:

                          
On

                              Tue, Oct 07, 2014 at 11:17:15AM -0700,
                              Eric Rescorla wrote:

                              > Folks,

                              >

                              > I've just made Pull Request 82, which
                              implements a number of

                              > the changes we discussed in Toronto,
                              including:

                              >

                              > - Merge in support for ECC from RFC
                              4492.

                              

                            Might be a good idea to allow curve
                            to specify a format for ECDHE.

                            This avoids trouble with "exotic" formats
                            (useful for what is

                            expected for CFRG curves[1] and some other
                            high-performance curves).

                          

                          


                          

                          
Yes, see the somewhat opaquely worded
                            note here:

                          
                        

                      

                    

                  

                  

                 Wouldn't it make sense not to overload this? 
                Keep the current code point for X9.62 curve based public
                data and assign a new code point to anything non-X9.62
                compliant?

              

            

            


            

            
Which code point are you referring to? Each curve will
              have its own code point

            
in any case.

          

        

      

    

    

    Sorry for my lack of clarity. "dhe-param" refers to X9.42
    diffie-hellman public data.  "ecdhe-param" currently refers to X9.62
    EC DH public data.   In some ways you could have had just the single
    "dhe-param" and use the type of algorithm to differentiate.

    

    select (algorithm) {

        dh:

            opaque dh_Y<1..2^16-1>; // positive big endian integer
    - could be encoded that way

        ec962:

            opaque point<1..2^8-1>; // x9.62 formatted point, odd
    number of bytes, first byte is compression type

        curve25519:

            opaque publicKey <255>; // don't beat me up on size;
    little endian integer on curve25519

    // other formats to come

    }

    

    

    So what I'm suggesting is that instead of changing the
    meaning/format of the "point" field in "ecdhe-param" to handle
    things like curve25519 or twisted edwards curves, to instead assign 
    "ec25519dhe-param" or "tedhe-param" when and if the CFRG gets around
    to blessing them.  

    

    The math is different, the proposed formats are different etc.

    

    Otherwise, you might want to signal the possibility that this isn't
    just an X9.62 point as:

    

    select (curvetype) { // implicit

         x962: 

             opaque point <1..2^8-1>;

    // more curve types to come.

    }

    

    which may have been Ilari's point.

    

    

    

      

        

          

            


            

            
In any case, the intent with the current draft is
              simply to cover the current

            
X9.62 compatible forms and then deal with whatever the
              CFRG comes out

            
with once that's finalized.

          

        

      

    

    

    Yup.  But always dealing with possible backwards compatibility.   If
    your intention is to overload ecdhe_param for the new curves, then
    it would be useful to provide the right encoding/implementation
    hints.  If you're going to allocate new code points for each
    parameter type, then there's nothing that needs changes right now.

    

    

    

    BTW -you should probably change "ecdh_Y" to "ecdh_XY" in this line:

    
The opaque value conveys the Elliptic +Curve
      Diffie-Hellman public value (ecdh_Y)

    

    Mike

    

    

    

      

        

          

            


            

            
-Ekr

            
 

          

        

      

    

    

  


--------------080704000908050101020600--


From nobody Thu Oct  9 12:54:01 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BC31A1A06 for ; Thu,  9 Oct 2014 12:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPm5N860h5yD for ; Thu,  9 Oct 2014 12:53:58 -0700 (PDT)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598481A19FB for ; Thu,  9 Oct 2014 12:53:58 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id n3so28746wiv.3 for ; Thu, 09 Oct 2014 12:53:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CTvBG01uobM+zplgad6KrCJBH667u7Tm/t0xByF80+Q=; b=WtMlF1yuiw1gkLagQVlzSayrTpUsO8WwfhBMH3X4wla/PrWsE7CTB6Cx11zQWd+ko4 qmyyj/2akBLIxy6RbcOAckZtVKhuyG3kDVSpn7KnfSY5OIZbVZMuvQTWmNG0GD6BT4sy 5aNOKkvQesXyCVPd0F2bdXEVyY2N+XnvPCdKyEbIzwb7pwBq8eBm+25cTDTpmrim08Lo KcFHYoGTQlVI8y9xnxa6zB4VpELgxS5FwYHDricRcqMlzoq4tJJLVpPEBeFfDjsW2EGm Y0vzGZBYGL3Pnn5rebiy6vMCLnhkX9X1fwLlL8/p2WkAo5YjypYMi0KVvraUU1qtMtGx uxTQ==
X-Gm-Message-State: ALoCoQmaYwx81ZxpWWdT7GR42Qn00FRQXT20zDJK/aENTM1Hl77yUe17HwLBp2YkE/rj1W8pVmND
X-Received: by 10.180.91.52 with SMTP id cb20mr140346wib.61.1412884436940; Thu, 09 Oct 2014 12:53:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.130.130 with HTTP; Thu, 9 Oct 2014 12:53:16 -0700 (PDT)
In-Reply-To: <5436E171.3070007@nthpermutation.com>
References:  <20141007193512.GA32644@LK-Perkele-VII>  <5436CE97.8040107@nthpermutation.com>  <5436E171.3070007@nthpermutation.com>
From: Eric Rescorla 
Date: Thu, 9 Oct 2014 12:53:16 -0700
Message-ID: 
To: Michael StJohns 
Content-Type: multipart/alternative; boundary=f46d0438eeaff932f8050502caff
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/roXmrojBceZ8ZoTkmTEodN97HVk
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Pull Request #82: Merge in ECC and Negotiated FF-DHE
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 19:54:01 -0000

--f46d0438eeaff932f8050502caff
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 9, 2014 at 12:26 PM, Michael StJohns 
wrote:

>  On 10/9/2014 2:36 PM, Eric Rescorla wrote:
>
>
>
> On Thu, Oct 9, 2014 at 11:06 AM, Michael StJohns 
> wrote:
>
>>  On 10/7/2014 5:45 PM, Eric Rescorla wrote:
>>
>>
>>
>> On Tue, Oct 7, 2014 at 12:35 PM, Ilari Liusvaara <
>> ilari.liusvaara@elisanet.fi> wrote:
>>
>>> On Tue, Oct 07, 2014 at 11:17:15AM -0700, Eric Rescorla wrote:
>>> > Folks,
>>> >
>>> > I've just made Pull Request 82, which implements a number of
>>> > the changes we discussed in Toronto, including:
>>> >
>>> > - Merge in support for ECC from RFC 4492.
>>>
>>> Might be a good idea to allow curve to specify a format for ECDHE.
>>> This avoids trouble with "exotic" formats (useful for what is
>>> expected for CFRG curves[1] and some other high-performance curves).
>>>
>>
>>  Yes, see the somewhat opaquely worded note here:
>>
>> https://github.com/tlswg/tls13-spec/pull/82/files#diff-9d84740dcc569a0a5a359d0fba461a05R1968
>>
>>
>>  Wouldn't it make sense not to overload this?  Keep the current code
>> point for X9.62 curve based public data and assign a new code point to
>> anything non-X9.62 compliant?
>>
>
>  Which code point are you referring to? Each curve will have its own code
> point
> in any case.
>
>
> Sorry for my lack of clarity. "dhe-param" refers to X9.42 diffie-hellman
> public data.  "ecdhe-param" currently refers to X9.62 EC DH public data.
> In some ways you could have had just the single "dhe-param" and use the
> type of algorithm to differentiate.
>
> select (algorithm) {
>     dh:
>         opaque dh_Y<1..2^16-1>; // positive big endian integer - could be
> encoded that way
>     ec962:
>         opaque point<1..2^8-1>; // x9.62 formatted point, odd number of
> bytes, first byte is compression type
>     curve25519:
>         opaque publicKey <255>; // don't beat me up on size; little endian
> integer on curve25519
> // other formats to come
> }
>
>
> So what I'm suggesting is that instead of changing the meaning/format of
> the "point" field in "ecdhe-param" to handle things like curve25519 or
> twisted edwards curves, to instead assign  "ec25519dhe-param" or
> "tedhe-param" when and if the CFRG gets around to blessing them.
>
> The math is different, the proposed formats are different etc.
>
> Otherwise, you might want to signal the possibility that this isn't just
> an X9.62 point as:
>
> select (curvetype) { // implicit
>      x962:
>          opaque point <1..2^8-1>;
> // more curve types to come.
> }
>
> which may have been Ilari's point.
>
>
>
>  In any case, the intent with the current draft is simply to cover the
> current
> X9.62 compatible forms and then deal with whatever the CFRG comes out
> with once that's finalized.
>
>
> Yup.  But always dealing with possible backwards compatibility.   If your
> intention is to overload ecdhe_param for the new curves, then it would be
> useful to provide the right encoding/implementation hints.  If you're going
> to allocate new code points for each parameter type, then there's nothing
> that needs changes right now.
>

I don't think there's really a backward compatibility problem since it
seems likely that
we'll have the new curves before we finalize TLS 1.3, so I'm going to leave
this as-is
for now.



> BTW -you should probably change "ecdh_Y" to "ecdh_XY" in this line:
>
> The opaque value conveys the Elliptic +Curve Diffie-Hellman public value
> (ecdh_Y)
>
>
It's this way in RFC 4492.


-Ekr


> Mike
>
>
>
>  -Ekr
>
>
>
>

--f46d0438eeaff932f8050502caff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 9, 2014 at 12:26 PM, Michael StJohns <=
msj@nthpermutat=
ion.com> wrote:

 =20
   =20
 =20
  

    
On 10/9/2014 2:36 PM, Eric Rescorla
      wrote:

    

    

      


        


          
On Thu, Oct 9, 2014 at 11:06 AM,
            Michael StJohns <msj@nthpermutation.com>
            wrote:

            

              

                  
On 10/7/2014 5:45 PM, Eric Rescorla wrote:

                  

                  

                    


                      


                        
On Tue, Oct 7, 2014 at
                          12:35 PM, Ilari Liusvaara <<=
a href=3D"mailto:ilari.liusvaara@elisanet.fi" target=3D"_blank">ilari.liusv=
aara@elisanet.fi>
                          wrote:

                          
On

                              Tue, Oct 07, 2014 at 11:17:15AM -0700,
                              Eric Rescorla wrote:

                              > Folks,

                              >

                              > I've just made Pull Request 82, whic=
h
                              implements a number of

                              > the changes we discussed in Toronto,
                              including:

                              >

                              > - Merge in support for ECC from RFC
                              4492.

                              

                            Might be a good idea to allow curve
                            to specify a format for ECDHE.

                            This avoids trouble with "exotic" for=
mats
                            (useful for what is

                            expected for CFRG curves[1] and some other
                            high-performance curves).

                          

                          


                          

                          
Yes, see the somewhat opaquely worded
                            note here:

                          
                        

                      

                    

                  

                  

                 Wouldn't it make sense not to overload this?=C2=
=A0
                Keep the current code point for X9.62 curve based public
                data and assign a new code point to anything non-X9.62
                compliant?

              

            

            


            

            
Which code point are you referring to? Each curve will
              have its own code point

            
in any case.

          

        

      

    

    

    Sorry for my lack of clarity. "dhe-param" refers to X9.42
    diffie-hellman public data.=C2=A0 "ecdhe-param" currently ref=
ers to X9.62
    EC DH public data.=C2=A0=C2=A0 In some ways you could have had just the=
 single
    "dhe-param" and use the type of algorithm to differentiate.
    

    select (algorithm) {

    =C2=A0=C2=A0=C2=A0 dh:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 opaque dh_Y<1..2^16-1>=
; // positive big endian integer
    - could be encoded that way

    =C2=A0=C2=A0=C2=A0 ec962:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 opaque point<1..2^8-1>=
; // x9.62 formatted point, odd
    number of bytes, first byte is compression type

    =C2=A0=C2=A0=C2=A0 curve25519:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 opaque publicKey <255>=
; // don't beat me up on size;
    little endian integer on curve25519

    // other formats to come

    }

    

    

    So what I'm suggesting is that instead of changing the
    meaning/format of the "point" field in "ecdhe-param"=
; to handle
    things like curve25519 or twisted edwards curves, to instead assign=C2=
=A0
    "ec25519dhe-param" or "tedhe-param" when and if the=
 CFRG gets around
    to blessing them.=C2=A0 

    

    The math is different, the proposed formats are different etc.

    

    Otherwise, you might want to signal the possibility that this isn't
    just an X9.62 point as:

    

    select (curvetype) { // implicit

    =C2=A0=C2=A0=C2=A0=C2=A0 x962: 

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 opaque point <1..2^=
8-1>;

    // more curve types to come.

    }

    

    which may have been Ilari's point.

    

    

    

      

        

          

            


            

            
In any case, the intent with the current draft is
              simply to cover the current

            
X9.62 compatible forms and then deal with whatever the
              CFRG comes out

            
with once that's finalized.

          

        

      

    

    

    Yup.=C2=A0 But always dealing with possible backwards compatibility.=C2=
=A0=C2=A0 If
    your intention is to overload ecdhe_param for the new curves, then
    it would be useful to provide the right encoding/implementation
    hints.=C2=A0 If you're going to allocate new code points for each
    parameter type, then there's nothing that needs changes right now.<=
br>

I don't think there's rea=
lly a backward compatibility problem since it seems likely that
w=
e'll have the new curves before we finalize TLS 1.3, so I'm going t=
o leave this as-is
for now.

=C2=A0
=

BT=
W -you should probably change "ecdh_Y" to "ecdh_XY" in =
this line:

    
The opaque value conveys the Elliptic +Curve
      Diffie-Hellman public value (ecdh_Y)
<=
div>
It's this way in RFC 4492.

=

-Ekr
=C2=A0

    Mike

    

    

    

      

        

          

            


            

            
-Ekr

            
=C2=A0

          

        

      

    

    

  






--f46d0438eeaff932f8050502caff--


From nobody Thu Oct  9 20:48:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81FF1A00E2 for ; Thu,  9 Oct 2014 20:48:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cFttEvwPfVX for ; Thu,  9 Oct 2014 20:48:14 -0700 (PDT)
Received: from mail-qa0-f65.google.com (mail-qa0-f65.google.com [209.85.216.65]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE641A00BA for ; Thu,  9 Oct 2014 20:48:14 -0700 (PDT)
Received: by mail-qa0-f65.google.com with SMTP id i13so376578qae.0 for ; Thu, 09 Oct 2014 20:48:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=yl3vuVpdG/yxlY78Ni4nTKtyQPifi0DX17X4yCo7LX8=; b=ZXM2xe0bFGBj9dO4YEAA0fUjV9xF4YeHOsqO1tlBbGKW0u4Q/oD8GT3grxVoPwyjUO lMVLjF6xmPBN4dBAQThsbszzf54EcgUVD9DErRt1UcgV38e4wEq8k3DZk5R8rEj06qd5 VBLW3MJKDPHXNayH4IQVApM+aXWaekYUv0TwhZmJMVjqwwRSj59XSW5U7x8m/JE79LH4 WkpwbS00oIjgb7fIAiYeLzfuujzJ5FnGMxV2eaBmryipqE+R1kYwePoGtn3gLoXjNKIm 5efmlP2cXq6K75KnfVhDzyLRp0jEGbnowdKAc4toOjuC1kdz8yZ8980iUTU0RcAab3j/ UKpg==
X-Gm-Message-State: ALoCoQk2rK7zAG2tBICTgS+tgogC930XXgDu2/B5yBQetVkJ4GQadhFK4M4gHSr4ELIhEC4N5rv9
MIME-Version: 1.0
X-Received: by 10.140.86.17 with SMTP id o17mr3881356qgd.71.1412912893508; Thu, 09 Oct 2014 20:48:13 -0700 (PDT)
Received: by 10.96.228.164 with HTTP; Thu, 9 Oct 2014 20:48:13 -0700 (PDT)
X-Originating-IP: [2601:8:b300:a5:65bd:2e8e:1fbf:9ccf]
Date: Thu, 9 Oct 2014 20:48:13 -0700
Message-ID: 
From: Joseph Salowey 
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=001a11c126221dd4840505096b2d
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d2XpLBzPcuQ6b7p8ug1lr2_0bJ0
Subject: [TLS] Pre-IETF Interim
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 03:48:15 -0000

--001a11c126221dd4840505096b2d
Content-Type: text/plain; charset=UTF-8

We're trying to organize a pre-ietf interim meeting on Sunday 11/9 in
Honolulu.  Please use the following Doodle poll to indicate if you would be
able to make this meeting.

http://doodle.com/cmaifz5f6k58sk5s

Thanks,

Joe

--001a11c126221dd4840505096b2d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


We're trying to organize a pre-ietf interim meeting on=
 Sunday 11/9 in Honolulu.=C2=A0 Please use the following Doodle poll to ind=
icate if you would be able to make this meeting. =C2=A0


Thanks,

Joe


--001a11c126221dd4840505096b2d--


From nobody Thu Oct  9 21:12:29 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B25A1A0107 for ; Thu,  9 Oct 2014 21:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcT9P_QxeFR8 for ; Thu,  9 Oct 2014 21:12:24 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5D81A0103 for ; Thu,  9 Oct 2014 21:12:23 -0700 (PDT)
Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BD9F3509B6 for ; Fri, 10 Oct 2014 00:12:22 -0400 (EDT)
Message-ID: <54375C70.3000705@seantek.com>
Date: Thu, 09 Oct 2014 21:11:28 -0700
From: Sean Leonard 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: tls@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030301000200030202050104"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3XE4SqNcINxLGbPYOv_sfVIIYBc
Subject: Re: [TLS] Pre-IETF Interim
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 04:12:26 -0000

This is a cryptographically signed message in MIME format.

--------------ms030301000200030202050104
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

What is the proposed agenda of the pre-IETF interim meeting?

Sean

On 10/9/2014 8:48 PM, Joseph Salowey wrote:
> We're trying to organize a pre-ietf interim meeting on Sunday 11/9 in=20
> Honolulu.  Please use the following Doodle poll to indicate if you=20
> would be able to make this meeting.
>
> http://doodle.com/cmaifz5f6k58sk5s
>
> Thanks,
>
> Joe



--------------ms030301000200030202050104
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKTDCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcN
AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD
T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMx
MTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRkZXYraWV0ZkBz
ZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J9tKgDs1LQtaD
c+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2guKi2R5xr
f/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G53zv
awQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8
lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia3
3JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaA
FHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAO
BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB
BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB
MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQ
ME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp
Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcw
AoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h
bmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IB
AQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMfWE2/5myX518DB+kTa5iQDbKYRuJp
3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmIH4kfI4LWrY8XrPhlX3JmHjD6
hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3jx9VF/gA3vqYpL+jNumI
nz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d9ljRDEiAts5Oopke
eFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYIEHDCCBBgCAQEw
gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV
BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P
RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu
psyQvhKSvQd8MAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTE0MTAxMDA0MTEyOFowIwYJKoZIhvcNAQkEMRYEFDc39EkGfqRGSUPJ
vUCkPbXd2m55MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNV
BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09N
T0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwgbwGCyqGSIb3DQEJEAIL
MYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw
DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw
Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAypM8
MbupbqbMkL4Skr0HfDANBgkqhkiG9w0BAQEFAASCAQA6vLTK1fOv6e/KkI7kKRKCS19UP2tU
QBZVjTVP/BxieKBoQMAU6/NScXXfrDWXah2ps++h11mUNRNeocSOGXueNrwYHcyZw4qjqHdC
EY8rLI1yPRShN1T2xKS4R9ZFMaFuUax5nKa4lgwLCuoBkbUQe0xieHPKI9mYCvd/znclr8Yi
4I6wkj5Laollw6ZvHBdAH4PgoH91aNOGUEkU5PzH5kYzVoc680RvbrjBLbMlUKNc+CugHvF/
uF1oL/J29GV9lA2csJ3thZ/oX3v0gxvFhDLrVpsVSimsCTCSMY+5FVUqodWNwZzNR/1dwkV0
6bFlmf0I4fwYGOSvnRJEf/vCAAAAAAAA
--------------ms030301000200030202050104--


From nobody Fri Oct 10 07:32:12 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814D31ACE14 for ; Fri, 10 Oct 2014 07:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level: 
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AW8iYGXoS_B for ; Fri, 10 Oct 2014 07:32:08 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8B41A1A18 for ; Fri, 10 Oct 2014 07:32:07 -0700 (PDT)
Received: (qmail 17112 invoked by uid 1000); 10 Oct 2014 14:32:05 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 10 Oct 2014 15:32:05 +0100
Message-ID: <5437EDE5.6020208@comodo.com>
Date: Fri, 10 Oct 2014 15:32:05 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Watson Ladd ,  Phillip Hallam-Baker 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fpdCPb6S5953_KTdoh7_LtEVcVo
Cc: "tls@ietf.org" 
Subject: Re: [TLS] New directions in certificate status
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 14:32:11 -0000

On 09/10/14 16:07, Watson Ladd wrote:
> On Wed, Oct 8, 2014 at 6:07 PM, Phillip Hallam-Baker
>  wrote:
>> Please note:
>>
>> http://datatracker.ietf.org/doc/draft-hallambaker-compressedcrlset/
>> Also note the pending IPR disclosure.
>>
>> In brief Rob Stradling and myself have come up with a radically new
>> approach to certificate status that is vastly more efficient than any
>> previous proposal that provides finer grain certificate status than
>> the certificate validity interval.
>
> Good idea. Unfortunately the draft is incomprehensible: key details
> are missing. If understand this correctly, the idea is to use a
> crit-bit tree to encode the certificate serial numbers, by removing
> common prefixes. There are a lot of finicky details to specify, but
> this should help.
>
> What would be nice is some hard numbers on how much it helps.

Hi Watson.  I won't comment on the methods right now, but here are some 
hard numbers from my experimental code...

Using a snapshot of Google's Pilot/Aviator CT logs from mid-June, I 
counted 2,616,669 unexpired-and-publicly-trusted certs useable for TLS 
Server Authentication.  I grabbed all of the applicable CRLs that were 
available online and found that 286,875 of these certificates were revoked.

Size of the resulting "Compressed CRLSet": ~182K

That's ~6 bits per unexpired-and-revoked-and-publicly-trusted TLS Server 
Certificate.
Or, to make it sound more impressive, ~0.6 bits per 
unexpired-and-publicly-trusted TLS Server certificate.



-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From nobody Fri Oct 10 08:15:21 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0D81A02D7 for ; Fri, 10 Oct 2014 08:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.786
X-Spam-Level: 
X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzPNyZbSIlqJ for ; Fri, 10 Oct 2014 08:15:18 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id A84291A008C for ; Fri, 10 Oct 2014 08:15:04 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2BE73484C9 for ; Fri, 10 Oct 2014 15:15:04 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 201F3484F5 for ; Fri, 10 Oct 2014 15:15:04 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id F097998041 for ; Fri, 10 Oct 2014 15:15:03 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Fri, 10 Oct 2014 11:15:03 -0400
From: "Salz, Rich" 
To: "TLS@ietf.org (tls@ietf.org)" 
Date: Fri, 10 Oct 2014 11:15:02 -0400
Thread-Topic: Paris logistics
Thread-Index: Ac/knJQsE16cuzObShCE3OBl2Zv7ag==
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECDE81@USMBX1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71D39ECDE81USMBX1msgcorp_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MlRsQdx0Juoh8mRIiqSQc2a4SuA
Subject: [TLS] Paris logistics
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 15:15:20 -0000

--_000_2A0EFB9C05D0164E98F19BB0AF3708C71D39ECDE81USMBX1msgcorp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I'm arriving in Paris on Sunday 19 Oct around 1700 and staying at the Ibis =
Paris hotel.  If anyone else is arriving early and would like to grab food =
or a museum or such, drop me a line.  I believe my phone number will be 617=
 953 1060.

--
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


--_000_2A0EFB9C05D0164E98F19BB0AF3708C71D39ECDE81USMBX1msgcorp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I’m arrivi=
ng in Paris on Sunday 19 Oct around 1700 and staying at the Ibis Paris hote=
l.  If anyone else is arriving early and would like to grab food or a =
museum or such, drop me a line.  I believe my phone number will be 617=
 953 1060.
 
--  
Principal Securit=
y Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz
 
=

--_000_2A0EFB9C05D0164E98F19BB0AF3708C71D39ECDE81USMBX1msgcorp_--


From nobody Fri Oct 10 08:51:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC6A1A1AED for ; Fri, 10 Oct 2014 08:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnkclaoc3I80 for ; Fri, 10 Oct 2014 08:51:41 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811BE1A1A27 for ; Fri, 10 Oct 2014 08:51:41 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B09E62AACFF; Fri, 10 Oct 2014 15:51:39 +0000 (UTC)
Date: Fri, 10 Oct 2014 15:51:39 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141010155139.GA13254@mournblade.imrryr.org>
References:   <5437EDE5.6020208@comodo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5437EDE5.6020208@comodo.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fPC7ZxyCH3ERvcof2FoTjNnuDUM
Subject: Re: [TLS] New directions in certificate status
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 15:51:43 -0000

On Fri, Oct 10, 2014 at 03:32:05PM +0100, Rob Stradling wrote:

> Size of the resulting "Compressed CRLSet": ~182K
> 
> That's ~6 bits per unexpired-and-revoked-and-publicly-trusted TLS Server
> Certificate.

Is this compressed across multiple issuing CAs?  If so who signs
the validity of such a list?  Is the expectation that CRLs will be
vetted and curated by browser vendors (with frequent updates over
a suitably secure channel)?

How does this interact with intramural CRLs maintained by organizations
on their non-public internal networks?  I am guessing this would
be a complementary mechanism.

If this is frequently updated data, would it not be more efficient
to just send the newly expired (CA, serial) pairs when updating,
rather than compressing the whole set.  At which point how important
is the initial compression?

-- 
	Viktor.


From nobody Fri Oct 10 09:22:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238411A87CD for ; Fri, 10 Oct 2014 09:22:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA45uzAug0-I for ; Fri, 10 Oct 2014 09:22:31 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30BDB1A8ABA for ; Fri, 10 Oct 2014 09:18:12 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id w7so3419971lbi.36 for ; Fri, 10 Oct 2014 09:18:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=/CsEYXpN/WteHGT0Ng4xrIrZZ3MxbmXDzCl8LFkCikk=; b=LgNz3X7abCky0KADAVJjdHngyQPgldzAis/6gqdFsLkI6olOUM2QCix7OMIppMA+hA UKqnxRSKO2IF1rYOyoc5cw7ACVRUPf6AHqqym9fH4Z7POjltu0+hoB35Qw516d56iASm UFceJukIU1FVM7dv9tkvxhDFva1YocrMA8vGs+6Ujjad9yGT40PRp9P+Yu9Fsl5uLoGm eNuuu758Vx0+hHNuDZL+CHle1fRAf8ODbMcwWuSDPg1m7qicPTFRNwskXAKpddQqzeWE 5c4WQWS8p/9Us6/Y3TtZRt7dp7/FACqpIyK3lnrmHGihpVdB9lryqbIDY5K6ByY0CHZk fWqw==
MIME-Version: 1.0
X-Received: by 10.112.204.197 with SMTP id la5mr5878691lbc.2.1412957887929; Fri, 10 Oct 2014 09:18:07 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.66.196 with HTTP; Fri, 10 Oct 2014 09:18:07 -0700 (PDT)
In-Reply-To: <20141010155139.GA13254@mournblade.imrryr.org>
References:   <5437EDE5.6020208@comodo.com> <20141010155139.GA13254@mournblade.imrryr.org>
Date: Fri, 10 Oct 2014 12:18:07 -0400
X-Google-Sender-Auth: FomqNM2m7PMczAI1EHt33tvYqBU
Message-ID: 
From: Phillip Hallam-Baker 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XW-8DdkE-UlA_n2br8SF9-weISA
Subject: Re: [TLS] New directions in certificate status
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 16:22:33 -0000

On Fri, Oct 10, 2014 at 11:51 AM, Viktor Dukhovni
 wrote:
> On Fri, Oct 10, 2014 at 03:32:05PM +0100, Rob Stradling wrote:
>
>> Size of the resulting "Compressed CRLSet": ~182K
>>
>> That's ~6 bits per unexpired-and-revoked-and-publicly-trusted TLS Server
>> Certificate.
>
> Is this compressed across multiple issuing CAs?  If so who signs
> the validity of such a list?  Is the expectation that CRLs will be
> vetted and curated by browser vendors (with frequent updates over
> a suitably secure channel)?

It could be applied either way.

In fact this is part of what we need to discuss going forward because
there is more than one way we could deploy this technology.

One big CRL is one option. Separate CRLs produced by each CA is
another. A third possibility is we join separate CRLs into one large
distribution.

Given that we are already looking at TRANS deployment we might well
want to consider a mechanism that streamlines deployment of both.


> How does this interact with intramural CRLs maintained by organizations
> on their non-public internal networks?  I am guessing this would
> be a complementary mechanism.

I would have to think rather hard about that case. One side effect of
this technology is that the CRL leaks less information than a
traditional one. If all you have is a compressed CRL then you know the
number of revoked certs but you don't know very much about any of
them. A traditional CRL tells you all the serial numbers which might
well leak rather a lot of data.


> If this is frequently updated data, would it not be more efficient
> to just send the newly expired (CA, serial) pairs when updating,
> rather than compressing the whole set.  At which point how important
> is the initial compression?

Delta CRLs have been tried in the past. The problem is that the
relying party still needs to store the serial number of every revoked
certificate. And it gets worse because it is harder to purge the list
for expired certs.


From nobody Fri Oct 10 12:32:56 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C4B1ACEFB; Fri, 10 Oct 2014 12:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level: 
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYoEKLn7EeuA; Fri, 10 Oct 2014 12:32:46 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB21C1ACEF9; Fri, 10 Oct 2014 12:32:42 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 58B2BDBDB18B7; Fri, 10 Oct 2014 19:32:37 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9AJWegY004917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 21:32:40 +0200
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.75]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 21:32:40 +0200
From: "Schwarz, Albrecht (Albrecht)" 
To: "megaco@ietf.org" , "TLS@ietf.org" 
Thread-Topic: Terminology related to TLS and DTLS; RE: TLS 1.3: Enhanced definitions of terms "TLS session" and "TLS connection"
Thread-Index: Ac9DjZ+ZjmG0vyWtSwSda/q5qX0LqCg9SQKw
Date: Fri, 10 Oct 2014 19:32:40 +0000
Message-ID: <786615F3A85DF44AA2A76164A71FE1AC33F0C0@FR711WXCHMBA03.zeu.alcatel-lucent.com>
References: <786615F3A85DF44AA2A76164A71FE1AC1B5B78@FR711WXCHMBA03.zeu.alcatel-lucent.com>
In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC1B5B78@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZoQhHkzYlS4zihqjVnfnAKz9Lts
Cc: "3GPP_TSG_SA_WG3@LIST.ETSI.ORG" <3GPP_TSG_SA_WG3@LIST.ETSI.ORG>, "3GPP_TSG_CT_WG4@LIST.ETSI.ORG" <3GPP_TSG_CT_WG4@LIST.ETSI.ORG>
Subject: [TLS] Terminology related to TLS and DTLS; RE: TLS 1.3: Enhanced definitions of terms "TLS session" and "TLS connection"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 19:32:48 -0000

fyi,
we've developed an hierarchical terminology framework for TLS and DTLS (in =
context of H.248 gateways, serving the termination or interworking of (D)TL=
S protocol).
However, the terminology isn't gateway specific, defined in a general manne=
r, thus applicable (and fully consistent) to IETF TLS RFCs in our understan=
ding.

Download:
AVD-4600 H.Sup.13 (Rel. 2): Terminology related to TLS and DTLS
http://wftp3.itu.int/av-arch/avc-site/2013-2016/1411_Seo/AVD-4600.zip =20

Regards,

Albrecht, Jens & Juergen

PS
The formal proceeding behind AVD-4600 may be found in:
AVD-4614 Backup-material to AVD-4600: Formal description of "TLS terminolog=
y framework"
http://wftp3.itu.int/av-arch/avc-site/2013-2016/1411_Seo/AVD-4614.zip=20

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Schwarz, Albrecht (Alb=
recht)
Sent: Mittwoch, 19. M=E4rz 2014 17:10
To: TLS@ietf.org
Subject: [TLS] TLS 1.3: Enhanced definitions of terms "TLS session" and "TL=
S connection"

Dear All,
like to raise a question related to the RFC 5246, Appendix B "Glossary":

Status:=20
- connection:=09
       A connection is a transport (in the OSI layering model definition) t=
hat provides a suitable type of service.  For TLS, such connections are pee=
r-to-peer relationships.  The connections are transient.  Every connection =
is associated with one session.

- session:=09
       A TLS session is an association between a client and a server. Sessi=
ons are created by the handshake protocol.  Sessions define a set of crypto=
graphic security parameters that can be shared among multiple connections. =
 Sessions are used to avoid the expensive negotiation of new security param=
eters for each connection.

Both terms are rather high-level and silent concerning a number of key char=
acteristics.
E.g.,
What constitutes exactly a "TLS session"? Just the 1-tuple of a "session id=
" or the 6-tuple of {session identifier, peer certificate, compression meth=
od, cipher spec, master secret, is resumable}" (based on clause 7/RFC 5246)=
?

Similar, what constitues exactly a "TLS connection"? An n-tuple based on th=
e ConnectionState on clause 6.1/RFC 5246, just a sub-set ..., the 5-tuple o=
f IP transport connection endpoint addresses?

What exactly is the relation between a "TLS session" and its associated "TL=
S connection(s)"?

Resumption of a "TLS session"? What kind of "data object (configuration)" i=
s exactly used as starting point for the "resumption procedure"?

Such kind of questions are all leading to the baseline of good terminology.=
 The existing Glossary could and should be improved in my understanding.

Any opinions, comments from TLS expert side?
Anyone aware of similar terminology enhancements requests in the past?

Thanks,
Albrecht


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From SRS0=LxXc=7B=acm.org=bmoeller@srs.kundenserver.de  Fri Oct 10 12:52:30 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82081ACF55 for ; Fri, 10 Oct 2014 12:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.714
X-Spam-Level: 
X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4768IqMdsaj for ; Fri, 10 Oct 2014 12:52:29 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F0D1ACF54 for ; Fri, 10 Oct 2014 12:52:29 -0700 (PDT)
Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0LkjTw-1YD7S31Ujk-00aSeX; Fri, 10 Oct 2014 21:52:27 +0200
Received: by mail-qg0-f42.google.com with SMTP id z60so4468136qgd.15 for ; Fri, 10 Oct 2014 12:52:25 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.224.97.72 with SMTP id k8mr12091992qan.21.1412970745143; Fri, 10 Oct 2014 12:52:25 -0700 (PDT)
Received: by 10.140.156.5 with HTTP; Fri, 10 Oct 2014 12:52:24 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>        
Date: Fri, 10 Oct 2014 21:52:24 +0200
Message-ID: 
From: Bodo Moeller 
To: "" 
Content-Type: multipart/alternative; boundary=001a11c3e01857aba2050516e3ef
X-Provags-ID: V02:K0:otpAipRRdfpYKavu8+5QB6f6kUVyt57prfphTBC0ySq DMHPK9WgKoB88xBwA/1nwPHpj1eaRuv4PoYta0qpM5QGSFy+Jd 7TaQ6n4zfo9PV2fAkYaF/jWcVZ8jBV/ugLEl81gXO+BEyMTvsS f9s/7ONoPJtJzEO2CVCXt0eCF4kVpWRPM6OvYCFA6vZvk6qxa/ 8tChgvMd4hp2kV/H5XPqCFb4Hy7DYQLBFsjCIb5dfRo5j1TKCS as7tDlekJEyMywUr+8+zXcLD6j9vpCBLDBa4MAfq0HnQATasm4 TcZGfKDW+XUtdC++WdKv/WZAX1Trdaccvm1pqX20x5NpmRmnN8 mj+3/HF3zwVh6ueNP+jbuLzzlfpjlaN5XvasTWtKtFMeR/tner +NVWosTvYKlQTYfCAuudnkDzKWJwrxRo+W6Jmfrmqh71YAle5B 0CWMj
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w9Fhx6P7ljNWrUt0L_sKqMiYyzs
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 19:53:22 -0000

--001a11c3e01857aba2050516e3ef
Content-Type: text/plain; charset=UTF-8

Brian Smith :

>       However, as an exception to the above, when the client intends to
> >       perform an abbreviated handshake to resume a previously negotiated
> >       session and sets ClientHello.client_version to the protocol
> >       version negotiated for that session, the client MUST NOT include
> >       TLS_FALLBACK_SCSV in ClientHello.cipher_suites.
> >
> > So, if the client does NOT set ClientHello.client_version to the
> > version negotiated for that session, then the client MAY send the SCSV
> > in the resumption handshake.
>


> Bodo, could you please reword the above to make it clearer?
>

Maybe I should rather change it?

"However, when the client intends to
perform an abbreviated handshake to resume a previously negotiated
session and sets ClientHello.client_version to the protocol
version negotiated for that session, the client MAY omit
TLS_FALLBACK_SCSV from ClientHello.cipher_suites
even if that version is lower than the latest version supported by the
client.

(Given that the protocol version has previously been negotiated
between the client and server, TLS_FALLBACK_SCSV is only
expected to have an effect if the server has since been updated
to support higher versions. Omitting TLS_FALLBACK_SCSV
lets the client continue to use the previously negotiated protocol
version. Sending TLS_FALLBACK_SCSV, in contrast, could lead
to an inappropriate_fallback alert if the client should start anew
to create a new session using the new highest protocol version.)"

Previously I'd assumed you'd want to keep "normal" behavior (simply
continue to use the previous protocol version), but I don't see a
compelling reason for the specification to prescribe that to clients.

Bodo

--001a11c3e01857aba2050516e3ef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Bria=
n Smith <brian@briansmith.org>:


>=C2=A0 =C2=A0 =C2=A0 =C2=A0However, as an exception to the above, when =
the client intends to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0perform an abbreviated handshake to resume a=
 previously negotiated

>=C2=A0 =C2=A0 =C2=A0 =C2=A0session and sets ClientHello.client_version =
to the protocol

>=C2=A0 =C2=A0 =C2=A0 =C2=A0version negotiated for that session, the cli=
ent MUST NOT include

>=C2=A0 =C2=A0 =C2=A0 =C2=A0TLS_FALLBACK_SCSV in ClientHello.cipher_suit=
es.

>

> So, if the client does NOT set ClientHello.client_version to the

> version negotiated for that session, then the client MAY send the SCSV=


> in the resumption handshake.
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">
Bodo, could you please reword the above to make it clearer?

Maybe I should rather change it?

=

"However, when the client intends to
perform an abbrevia=
ted handshake to resume a previously negotiated
session and sets ClientH=
ello.client_version to the protocol
version negotiated for that session,=
 the client MAY omit
TLS_FALLBACK_SCSV from ClientHello.cipher_suites
even if that version is lower than the latest version supported=
 by the client.

(Given that the protocol version h=
as previously been negotiated
between the client and server, TLS_=
FALLBACK_SCSV is only
expected to have an effect if the server ha=
s since been updated
to support higher versions. Omitting TLS_FAL=
LBACK_SCSV
lets the client continue to use the previously negotia=
ted protocol
version. Sending TLS_FALLBACK_SCSV, in contrast, cou=
ld lead
to an inappropriate_fallback alert if the client should s=
tart anew
to create a new session using the new highest protocol =
version.)"

Previously I'd assumed you'=
;d want to keep "normal" behavior (simply continue to use the pre=
vious protocol version), but I don't see a compelling reason for the sp=
ecification to prescribe that to clients.

Bodo



--001a11c3e01857aba2050516e3ef--


From nobody Fri Oct 10 13:08:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E901A6F17 for ; Fri, 10 Oct 2014 13:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6On0afkR1iwQ for ; Fri, 10 Oct 2014 13:08:29 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DBDD1A6FCE for ; Fri, 10 Oct 2014 13:07:45 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id ge10so3886667lab.24 for ; Fri, 10 Oct 2014 13:07:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q+E1uD2SuhoE7SIcKIHhoC8y4JJ0/SnWHarApvafQsg=; b=wODaJAUFpt36+iARk0hxvtDkU3s9yaBSYnCc6G9/DyxWtzX929T97SMG4N31YN1eyy yG++3qldX9xjfK5z4ImT01Rx3hdn6V/Qqtwtck1N9wbIk04YerEsQS/5aqUSr7EzKWsg ecoEGLDQeIYZ8AGufHmwHcCTKrcWFViMfV8XznlV4uteVRCGS9/bk6aDep0BP4wuFiIp aAVTcUSmFaJl3L1jkXmpoaJDvpt2ekjWIWj9+kINLsKTcWVxJlzKbdJEn+84neOyNAc5 RlZnkX2S0w6fc94JWcBOeDNNMEkZ7Mm+OXt5kvBLnGW60f6ODu/3NnAR4UkWW1Oa1JkI k/og==
MIME-Version: 1.0
X-Received: by 10.112.140.137 with SMTP id rg9mr5810425lbb.93.1412971663576; Fri, 10 Oct 2014 13:07:43 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Fri, 10 Oct 2014 13:07:43 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>         
Date: Fri, 10 Oct 2014 13:07:43 -0700
Message-ID: 
From: Martin Thomson 
To: Bodo Moeller 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kUAVc4XYbWp94p8b9MsECUe4evo
Cc: "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 20:08:31 -0000

On 10 October 2014 12:52, Bodo Moeller  wrote:
> Previously I'd assumed you'd want to keep "normal" behavior (simply continue
> to use the previous protocol version), but I don't see a compelling reason
> for the specification to prescribe that to clients.

Yes, that's in general a good change.

Maybe a small editorial concern with the following:

> "[...]  Sending TLS_FALLBACK_SCSV, in contrast, could lead
> to an inappropriate_fallback alert if the client should start anew
> to create a new session using the new highest protocol version.)"

This doesn't read particularly well to me.  It places the option to
create a new session as a condition on the first part of the
statement.

Maybe, "Sending TLS_FALLBACK_SCSV could lead to an
inappropriate_fallback alert. Clients that encounter an
inappropriate_fallback alert in response to a session resumption
attempt SHOULD use highest protocol version available to it when
connecting to that server."

I don't know if that's strictly better, but I hope that you catch my meaning.


From nobody Fri Oct 10 16:01:34 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2FF1AD463; Fri, 10 Oct 2014 16:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otJvh-azmbCH; Fri, 10 Oct 2014 16:01:28 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA1E1AD44C; Fri, 10 Oct 2014 16:01:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IESG Secretary 
To: IETF Announcement List 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3.p4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141010230128.29009.31779.idtracker@ietfa.amsl.com>
Date: Fri, 10 Oct 2014 16:01:28 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/X5TwPcl-p9zALWPrxUyD_ET-npk
Cc: tls@ietf.org
Subject: [TLS] TLS WG Interim Meeting, November 9, 2014
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 23:01:30 -0000

The TLS WG will hold an interim meeting in Honolulu prior to IETF 91 
on Sunday, November 9, 2014.

The chairs will post details with an agenda and a final location closer 
to the meeting.

Additional information will be announced on the TLS WG mailing list:
http://www.ietf.org/mail-archive/web/tls/current/maillist.html


From nobody Fri Oct 10 16:51:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100AA1A01D0 for ; Fri, 10 Oct 2014 16:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level: 
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV3hTaJcGfJw for ; Fri, 10 Oct 2014 16:51:27 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E361E1A00E4 for ; Fri, 10 Oct 2014 16:51:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8F6C9BE13 for ; Sat, 11 Oct 2014 00:51:25 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4z0oh0Coaud for ; Sat, 11 Oct 2014 00:51:24 +0100 (IST)
Received: from [10.87.48.8] (unknown [86.42.22.187]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3E778BE09 for ; Sat, 11 Oct 2014 00:51:24 +0100 (IST)
Message-ID: <543870F9.3030800@cs.tcd.ie>
Date: Sat, 11 Oct 2014 00:51:21 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: tls@ietf.org
References: <20141010230128.29009.31779.idtracker@ietfa.amsl.com>
In-Reply-To: <20141010230128.29009.31779.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jugdLX-MV-SbBFtZIN02bc28V1w
Subject: Re: [TLS] TLS WG Interim Meeting, November 9, 2014
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 23:51:30 -0000

I think this is still a placeholder for now and the chairs will
confirm details as they get feedback. This announcement goes out
once the interim is approved, which needed to be done now so
there was sufficient notice for folks.

S.

On 11/10/14 00:01, IESG Secretary wrote:
> The TLS WG will hold an interim meeting in Honolulu prior to IETF 91 
> on Sunday, November 9, 2014.
> 
> The chairs will post details with an agenda and a final location closer 
> to the meeting.
> 
> Additional information will be announced on the TLS WG mailing list:
> http://www.ietf.org/mail-archive/web/tls/current/maillist.html
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> 


From nobody Fri Oct 10 21:49:53 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108461A1AAB; Fri, 10 Oct 2014 21:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJo5L9AG-CEL; Fri, 10 Oct 2014 21:49:48 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB69F1A1AA6; Fri, 10 Oct 2014 21:49:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3.p4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141011044948.27553.93984.idtracker@ietfa.amsl.com>
Date: Fri, 10 Oct 2014 21:49:48 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/R06t-JSfLNMKx9OaaRVrMS1IxDI
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Oct 2014 04:49:50 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
        Author          : Daniel Kahn Gillmor
	Filename        : draft-ietf-tls-negotiated-ff-dhe-02.txt
	Pages           : 24
	Date            : 2014-10-10

Abstract:
   Traditional finite-field-based Diffie-Hellman (DH) key exchange
   during the TLS handshake suffers from a number of security,
   interoperability, and efficiency shortcomings.  These shortcomings
   arise from lack of clarity about which DH group parameters TLS
   servers should offer and clients should accept.  This document offers
   a solution to these shortcomings for compatible peers by using a
   section of the TLS "EC Named Curve Registry" to establish common DH
   parameters with known structure and a mechanism for peers to
   negotiate support for these groups.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Oct 10 21:55:25 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3702F1A1AAF for ; Fri, 10 Oct 2014 21:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqTgDsBLq7e7 for ; Fri, 10 Oct 2014 21:55:20 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 43F9D1A1AAB for ; Fri, 10 Oct 2014 21:55:20 -0700 (PDT)
Received: from [192.168.42.103] (h-67-101-29-238.nycm.ny.dynamic.megapath.net [67.101.29.238]) by che.mayfirst.org (Postfix) with ESMTPSA id 91917F984 for ; Sat, 11 Oct 2014 00:55:15 -0400 (EDT)
Message-ID: <5438B82B.6090600@fifthhorseman.net>
Date: Sat, 11 Oct 2014 00:55:07 -0400
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0
MIME-Version: 1.0
To: tls@ietf.org
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com>
In-Reply-To: <20141011044948.27553.93984.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EA55BGjFPXXiOR6xBaqJriubMB3Calucj"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_f-nBjvK3SUybLuD3iTm8SWGp3M
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Oct 2014 04:55:22 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EA55BGjFPXXiOR6xBaqJriubMB3Calucj
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 10/11/2014 12:49 AM, internet-drafts@ietf.org wrote:
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.
>  This draft is a work item of the Transport Layer Security Working Grou=
p of the IETF.
>=20
>         Title           : Negotiated Finite Field Diffie-Hellman Epheme=
ral Parameters for TLS
>         Author          : Daniel Kahn Gillmor
> 	Filename        : draft-ietf-tls-negotiated-ff-dhe-02.txt
> 	Pages           : 24
> 	Date            : 2014-10-10
>=20
> Abstract:
>    Traditional finite-field-based Diffie-Hellman (DH) key exchange
>    during the TLS handshake suffers from a number of security,
>    interoperability, and efficiency shortcomings.  These shortcomings
>    arise from lack of clarity about which DH group parameters TLS
>    servers should offer and clients should accept.  This document offer=
s
>    a solution to these shortcomings for compatible peers by using a
>    section of the TLS "EC Named Curve Registry" to establish common DH
>    parameters with known structure and a mechanism for peers to
>    negotiate support for these groups.


This update pushed the proposed syntactic changes to the ff-dhe draft,
dropping the explicit extension and making reuse of the NamedCurves
registry for finite field groups as well.

I'd appreciate any comments or suggestions, and particularly review
related to the IANA considerations would be great.

The xml2rfc source for the draft can be found (among other places) on
github:

 https://github.com/dkg/tls-negotiated-ff-dhe

patches welcome,

	--dkg


--EA55BGjFPXXiOR6xBaqJriubMB3Calucj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJUOLgrXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcclUQALnLeXtlrBQbpO4289sBHq+I
noVg5ME7iDHEq+I8vRL52qLkMYFFVHgsPvC90qQxAw8p9g93e+YWpRUOndav5Uhn
egw4nUFtyEgRC6OCc7VsLd7qSTY+v3Jo5Ry1g8Jflm03oC9UM5PTJLyTD4bs3vKB
G3P7uiyB68WTKyKmuV6Hg5OUwSzb8kfap9b6kxaVCrSgiyJTdrSRf86Q1N0WMzQe
r3HnADltswTYOkdhuqBKPChxQvOnlFXWzWz5Vii8dlJAwiZyYl7zbxrA4ufd2FNG
SbRNessDEuACrvXR43tXWorpfQqbU1FiMpQkyRzYoIyO+WuDaydqFUXeo0Db3jHu
sgVqF46Mb/eo4GvG2iM19BPT/lh9ZlLYHBEHlKM0Smlwj9u6uglwCi/+IEx2XOzV
S35GaGh+mdIKcu1rI8aedi2i3vTZnuXueYs97ScEenkMSGmOq2tUys9x7v5FqGsv
EEv2X59msU4AMtpwc6YwM5qhA0Iv3iyIf8dQzh07VDuwWSjYw0TjXf9TKUzH/wsE
eAfliqYmAtEuiHM6QzEwyGk4SqWo2G7rOTIMTv4CPEAn3KX9gFb5fcyYnI6kYkhe
34Pq6W9DNsyF5xxyNs/BNoDY5crFrdUwGuyXDSzJqAFWLwd4D5J/onmNVmwdXjmS
LquLR7I1uOMmHRsi0H5Z
=Rmii
-----END PGP SIGNATURE-----

--EA55BGjFPXXiOR6xBaqJriubMB3Calucj--


From nobody Fri Oct 10 22:07:46 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6611A1AB7 for ; Fri, 10 Oct 2014 22:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTAI-Oa2q_Oh for ; Fri, 10 Oct 2014 22:07:42 -0700 (PDT)
Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E12A1A1A8D for ; Fri, 10 Oct 2014 22:07:42 -0700 (PDT)
Received: by mail-oi0-f49.google.com with SMTP id a3so8582716oib.36 for ; Fri, 10 Oct 2014 22:07:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8RWJv99Xgzx+WA2OlF+N6vR764XRySYf4W9VKK6y1gg=; b=Jolqo+4tL+9S9tomgRIMfHGb8uQsOaphbiTRd3jvOpd27MxeyHDtbA+W3M6lHrCO4y QSStTyBQ4ja6Cj0snefeUHik5mmoA1OTtkVB0bVrP/iHtUsLxEkdMawUGhLa6GUAQqAi 0TMVYqBz9AV0lbPXb+GnYJXhp9NU/zRCoDF0YNFVAAsBdeRs4ERbfr8/g3wZvDcd4sEy FBFuoK9tBkd1+Xkxd4kJnrxyd4EuLEtqvd5sjWWHN4vGh26XnUayok0mqjwtoaJXJaCC FHPdZOFe1wb2HKBVEq3/tU1qlsI6E9Y1XxELhy6ZxmDmKbGFVRO235f4bgcAcwRyb4mm kYeg==
X-Gm-Message-State: ALoCoQk7+cbZ0fgE6DeuBkPnLkdVkHNkRI7tPA3zmlZ2pu79qs34I84I1SpCl3Sqwv2J0cD6cG4p
MIME-Version: 1.0
X-Received: by 10.182.215.131 with SMTP id oi3mr8803863obc.2.1413004061950; Fri, 10 Oct 2014 22:07:41 -0700 (PDT)
Received: by 10.76.102.40 with HTTP; Fri, 10 Oct 2014 22:07:41 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>         
Date: Fri, 10 Oct 2014 22:07:41 -0700
Message-ID: 
From: Brian Smith 
To: Bodo Moeller 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/doa3LxbT3dSTnWVFNJNlg38Hli0
Cc: "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Oct 2014 05:07:44 -0000

On Fri, Oct 10, 2014 at 12:52 PM, Bodo Moeller  wrote:
> (Given that the protocol version has previously been negotiated
> between the client and server, TLS_FALLBACK_SCSV is only
> expected to have an effect if the server has since been updated
> to support higher versions. Omitting TLS_FALLBACK_SCSV
> lets the client continue to use the previously negotiated protocol
> version. Sending TLS_FALLBACK_SCSV, in contrast, could lead
> to an inappropriate_fallback alert if the client should start anew
> to create a new session using the new highest protocol version.)"

Let's review the scenerio in detail:

1. Client attempts handshake with client_version == TLS 1.2, and the
handshake fails.
2. Client attempts handshake with client_version == TLS 1.1, and the
handshake succeeds, with both sides saving the session information.
3. Server is upgraded to support TLS 1.2 or higher.
4. Client attempts to handshake with client_version == TLS 1.1 and a
resumed session ticket.

There are four cases to consider:

CASE 1: Client included the TLS_FALLBACK_SCSV, server forgot session
state when it was upgraded. The result is an inappropriate_fallback
alert.

CASE 2: Client included the TLS_FALLBACK_SCSV, server (magically!!!)
retained the session state across the server software upgrade. The
result is an inappropriate_fallback alert.

CASE 3: Client did not include the TLS_FALLBACK_SCSV, the server
forgot session state when it was upgraded. The server starts a new TLS
1.1 session. Thus, the downgrade protection mechanism has failed to
prevent a version downgrade.

CASE 4: Client did not include the TLS_FALLBACK_SCSV, the server
(magically!!!) retained the session state across the software upgrade.
The server resumes the TLS 1.1 session instead of starting a new TLS
1.2 session. Thus, the downgrade protection mechanism has failed to
prevent a version downgrade.

> Previously I'd assumed you'd want to keep "normal" behavior (simply continue
> to use the previous protocol version), but I don't see a compelling reason
> for the specification to prescribe that to clients.

Doing that also allows version downgrade to succeed inappropriately in
the case where the server's capabilities were improved during the
lifetime of a session cached by a client.

I think the best solution is to take my original suggestion (i.e. keep
the current logic, but make it more clear), and also suggest that,
after the client has received an inappropriate_fallback alert, the
client SHOULD forget what it has learned about what the server's
version tolerance and cached sessions, and retry its version
intolerance logic over, taking care not to get into an infinite loop
in the even that it receives another inappropriate_fallback alert when
it retries.

I think it is realistic to expect that servers that implement the
inappropriate_fallback logic to implement at least TLS 1.2 (or at
least TLS 1.1), so you could also suggest that the client MUST (not
just SHOULD) send always send TLS_FALLBACK_SCSV when it negotiates TLS
1.1 or lower, because the "deployment of a new protocol version"
consideration does not apply for those versions.

If for some reason this cannot be done, then at a minimum the security
considerations need to be expanded to document that downgrade is still
possible in CASE 3 and CASE 4 above.

Cheers,
Brian


From nobody Fri Oct 10 23:36:31 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7201A1B0C for ; Fri, 10 Oct 2014 23:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RT-vRrNDT_FD for ; Fri, 10 Oct 2014 23:36:27 -0700 (PDT)
Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A2B1A1B1E for ; Fri, 10 Oct 2014 23:36:27 -0700 (PDT)
Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-02v.sys.comcast.net with comcast id 1icK1p0025AAYLo01icTnu; Sat, 11 Oct 2014 06:36:27 +0000
Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-15v.sys.comcast.net with comcast id 1icS1p0074uhcbK01icStC; Sat, 11 Oct 2014 06:36:27 +0000
Message-ID: <5438CFEA.7000401@brainhub.org>
Date: Fri, 10 Oct 2014 23:36:26 -0700
From: Andrey Jivsov 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
In-Reply-To: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413009387; bh=3rZ6XQjj276weYhJyAQmgzh+ntGhlc3w9sKeFg1LBSU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BsyqefbtUGz2GQC+SfHD3wrPF6kFlm2xpgl44aui9i7uvKfCFEVC2W+8hkY6XCAR+ mpHf7euejalBxODEXXiTerEAX3v6QVxAkQfPhh4HB4sLQrKauWv6iL185HvR1aEVaT O38vzOs5HLMfF02bvZuSGkX1dDBRa5ndYDF2ftHlBOoFD9teOW4eVthJKuk7Q4mIS4 jX5Rq/599DX5zrjamQQo3WlY80gvpsym0IZ853a+l4dOf+Wrwv6Je9FEEp3pEN1HI2 3CFVyATZoPRL7elA18gyne14Tz50FHZaiPQ+maJXJbzpsf4yBUS3Ff5whPbqPbufDA rjmf7q8XBvUIg==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JAnlhVQXYikQilSvMF8LO1bHXRY
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Oct 2014 06:36:29 -0000

On 09/25/2014 09:00 PM, Joseph Salowey (jsalowey) wrote:
> This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your comments to the list by Friday, October 17, 2014.
>
> Thanks,
> J&S


> 3. Server behavior

Suppose a server and a client support TLS1.2, client starts with TLS1.2 
but network failure makes the client reconnect with TLS1.1. Or perhaps 
there is an occasional bug in TLS1.2 path on the client or the server, 
leading to the same TLS1.1 reconnect.

In this case the server is prescribed to fail with 
inappropriate_fallback for TLS1.1 + SCSV.

* Assuming network failures, how does the client decide to continue with 
TLS1.1 ? (strictly speaking, this is not a "standard" behaviour)
* How should the client process the inappropriate_fallback?
* Has the server become "intolerant" when it issued 
inappropriate_fallback for TLS1.1 when it happily negotiates TLS1.0 and 
above "fresh"?

Is it possible that the majority of version-intolerant servers is 
limited to SSL2.0, SSL3.0 and TLS1.0 protocols? If so, would it be 
reasonable to expect that the servers supporting TLS 1.1 and above are 
maintainable and can be fixed "right", i.e. by making them compliant 
with the TLS spec?

( A general comment, it's reasonable to support two versions, {N, N+1} 
that are both considered secure at any given moment, as an gradual 
upgrade strategy, one of them on the way out. I think it looks odd to 
fail on N just because you happen to have N+1 supported. This is 
different when N is insecure. )


From nobody Sat Oct 11 01:19:59 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972331A009C for ; Sat, 11 Oct 2014 01:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAPKyE37dzqs for ; Sat, 11 Oct 2014 01:19:52 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D181A0095 for ; Sat, 11 Oct 2014 01:19:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413015593; x=1444551593; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=3q9aJ8fXWtjzZ3GczKFcrqmuIGw8VLJR2LcH8hQg7cA=; b=iiPEqBEM23SGcdu8GopuuYInlc2kMRPUR+zvHFAhD+BJeHeombgjQRLC fXnaMb0V2eJJ9r7AEBDcP3vkLaIHYN+wcK8gngqgn1QpTe5CexAxYm3LV DZOiuZ6RJqczDokBIPDukF6Wlv4QDmkTn8GOy9sqPzsz7Q/Yd6k5UXJgF I=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="282309792"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 11 Oct 2014 21:19:49 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sat, 11 Oct 2014 21:19:48 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
Thread-Index: Ac/lLB7PaWLf3f0KTgGivMGX060m1Q==
Date: Sat, 11 Oct 2014 08:19:47 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9C8F65@uxcn10-tdc05.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rNDoZ0PXt_h5mO4oUaGz3oSFfuk
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Oct 2014 08:19:56 -0000

Daniel Kahn Gillmor  writes:=0A=
=0A=
>I'd appreciate any comments or suggestions, and particularly review relate=
d=0A=
>to the IANA considerations would be great.=0A=
=0A=
It still doesn't include the widely-deployed IPsec groups (RFC 3526) that I=
=0A=
asked for last time round, or the RFC 5114 groups which specifically mentio=
n=0A=
use in TLS in their RFC.=0A=
=0A=
Peter.=


From nobody Sat Oct 11 08:09:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E741A6EFB for ; Sat, 11 Oct 2014 08:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9TxI-CkVVDF for ; Sat, 11 Oct 2014 08:09:12 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CA6161A6EE8 for ; Sat, 11 Oct 2014 08:09:11 -0700 (PDT)
Received: from [160.39.146.222] (dyn-160-39-146-222.dyn.columbia.edu [160.39.146.222]) by che.mayfirst.org (Postfix) with ESMTPSA id 5AD47F984; Sat, 11 Oct 2014 11:09:07 -0400 (EDT)
Message-ID: <54394811.60003@fifthhorseman.net>
Date: Sat, 11 Oct 2014 11:09:05 -0400
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0
MIME-Version: 1.0
To: Peter Gutmann , "" 
References: <9A043F3CF02CD34C8E74AC1594475C739B9C8F65@uxcn10-tdc05.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9C8F65@uxcn10-tdc05.UoA.auckland.ac.nz>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ur0qKqj6O0ECACFbMj7RAtPL8QTlQCK42"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5CunzLVLPw8D4rU2-GQqKApomdE
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Oct 2014 15:09:15 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Ur0qKqj6O0ECACFbMj7RAtPL8QTlQCK42
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Peter, thanks for the quick review.

On 10/11/2014 04:19 AM, Peter Gutmann wrote:
> Daniel Kahn Gillmor  writes:
>=20
>> I'd appreciate any comments or suggestions, and particularly review re=
lated
>> to the IANA considerations would be great.
>=20
> It still doesn't include the widely-deployed IPsec groups (RFC 3526) th=
at I
> asked for last time round, or the RFC 5114 groups which specifically me=
ntion
> use in TLS in their RFC.

yes, and that's a deliberate choice, as documented (perhaps not well
enough?) in the draft under "Choice of Groups".

I don't think we should include many groups (this leads to interop
issues and fingerprinting issues), so just adding to the list seems like
a bad idea.

Some of the MODP groups (768, 1024, 1536 at least) are also smaller than
we should be explicitly supporting in updated tools, so i don't think
re-blessing them into another standard is a good idea.

And if there is some fancy attack that needs expensive pre-computation
to work against a targeted group, we shouldn's expose both TLS and IPSEC
because they're sharing groups.

One counterargument i'm aware of is that systems that want to support
both sets of groups would need to have a larger table of known moduli.
So perhaps the argument is that extremely memory-constrained devices
running both TLS and IPSec (or TLS with SRP) could share a table of
known moduli to reduce RAM consumption?  I'm not convinced that this is
particularly important for modern hardware, or that there are many
deployments that meet this scope anyway.

The 5114 groups are small, have unusual generators, and the moduli don't
appear to be safe primes, so it's difficult to know if a peer is forcing
you into a small subgroup with their share -- am i mistaken on that?

We had a discussion about the use of e-derived safe primes instead of
pi-derived safe primes in Toronto, and no one seemed to think that the
groups currently proposed were any worse than the MODP groups.

So i'm not inclined to change this, unless there is a stronger argument
or more widespread opposition to it.

Should i add more of the above detail anywhere in the draft to make it
clear why it's set up this way?

	--dkg


--Ur0qKqj6O0ECACFbMj7RAtPL8QTlQCK42
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJUOUgRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpckjwQAK6ngpJI3WjFEtDhRzOJecaG
gBjsh3Wf0pZKc9pvT35Y7hJz3/DNU8ucmAPP+AKSzDq/vT8y5jRxcpSqjLXVJd4N
2R2ilsdTGbz5bC3WY7AwCDiseK0KVTeZCr3XlOcVWdDmNLgBN+j5yzo9WnZIr2Sk
/9Mf6y3WsrXwXIL2cWzwIUlOgHea8dnCykytcl6m47GkX8/oIaILvvK/G+Iu8OCn
CVR//9WS++fIldwHT3EFzHMJ9Q2b5p1jvzqf7T0JQuhaRoPgS3/6eJrCM+b5q3lW
S2msTvIJsI8jrT367AfIJ3oZGokj2MagXZ9qO1DESZpnqnvVbGAiQsYzdg6EZsQ4
IaN3jtsVdBBcybGiCV0QJHSPp406ICTQnS72VJyj6Bt9y8y70c+0vWDpThgAEE5o
bXnHU38m6l0ouwt8AM+TkZOAcQ39DsFasxWy2QDAnax5dC5JNOls6kaDUUnmYAFI
n3e1vA8nLUZ4XaXvMTbUSNz1ypVAHar1rmeR8WlnlCqkGHz0QBLq7Phror2mmany
iUj9CPzH4is4gdMXaIEjLpHzSBJgXACdDDDTbwFh3X+hKFl+RixfwUh0scSISNoh
UA4xrieO9n7nS4Tx7+/QaDUBOh7KODpvZdUPvhimXFCOLMBEpkMAd4CkB2CSLLGX
Cq8CYqR6TfdiOu0ZhX1x
=Wtkz
-----END PGP SIGNATURE-----

--Ur0qKqj6O0ECACFbMj7RAtPL8QTlQCK42--


From nobody Sun Oct 12 14:15:16 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9774F1A8AF0 for ; Thu,  9 Oct 2014 10:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyvFy8JvTKVd for ; Thu,  9 Oct 2014 10:17:45 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F421AD389 for ; Thu,  9 Oct 2014 10:15:44 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so2691378qgf.35 for ; Thu, 09 Oct 2014 10:15:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QTV3GSRmoEWcr4HMzXD2wyqm+IM7cA8kj1qbjUmvhwY=; b=E3dbLYgrJtkQ+PJE/gGYtcKXswqPvyj99AXTWdZbWSSl/HajgU5G8ksTJqX2XaJUrE ry/oG37dgOmfenwVLYr4IyUnLoMfipZ7qWsSxEMVi/tMP4uHdcm8wneMIpX+Oit/gRNP mbIy3PqUM2F+/X5/cN42kJfGabEdLhWXbH6xxTGsDRzowmkfQxzexrsOKOaS/5OJ+OMW HjASLLdIAHJVtG5aLa85JXKsVI1mI5it50oyed3pCZBc9bp75lyTXUh+Xs5ffO79fH98 PndzOLk5WKPsCvA+EYAgkwxggwbq2uwOswYVnEwfHB5WDU/XuklWTx6nFOhizLhJCDyx yIjg==
X-Received: by 10.229.131.65 with SMTP id w1mr26097239qcs.15.1412874943699; Thu, 09 Oct 2014 10:15:43 -0700 (PDT)
Received: from [10.228.134.253] (mobile-107-107-56-56.mycingular.net. [107.107.56.56]) by mx.google.com with ESMTPSA id p3sm2857726qaa.31.2014.10.09.10.15.42 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Oct 2014 10:15:42 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Phillip Hallam-Baker 
X-Mailer: iPhone Mail (12A405)
In-Reply-To: 
Date: Thu, 9 Oct 2014 13:15:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: Watson Ladd 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Qg9IIE3mSwqO0WxeqjB6JCTR_KM
X-Mailman-Approved-At: Sun, 12 Oct 2014 14:15:06 -0700
Cc: Phillip Hallam-Baker , "tls@ietf.org" 
Subject: Re: [TLS] New directions in certificate status
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 17:17:50 -0000

The intention is FRAND for application of the compression technique to certi=
ficate status.


The way it works is that we take the list of good certs A and the set of bad=
 certs B and we encode only the difference between A and B




Sent from my difference engine


> On Oct 9, 2014, at 11:07 AM, Watson Ladd  wrote:
>=20
> On Wed, Oct 8, 2014 at 6:07 PM, Phillip Hallam-Baker
>  wrote:
>> Please note:
>>=20
>> http://datatracker.ietf.org/doc/draft-hallambaker-compressedcrlset/
>> Also note the pending IPR disclosure.
>>=20
>> In brief Rob Stradling and myself have come up with a radically new
>> approach to certificate status that is vastly more efficient than any
>> previous proposal that provides finer grain certificate status than
>> the certificate validity interval.
>=20
> Good idea. Unfortunately the draft is incomprehensible: key details
> are missing. If understand this correctly, the idea is to use a
> crit-bit tree to encode the certificate serial numbers, by removing
> common prefixes. There are a lot of finicky details to specify, but
> this should help.
>=20
> What would be nice is some hard numbers on how much it helps.
>=20
>>=20
>> While compressing hash tables might appear to be a fools errand, it
>> turns out that if the problem is correctly understood, CRLs actually
>> compress astonishingly well. It is actually possible to represent the
>> status of every one of the half million revoked certificates in the
>> WebPKI using fewer bytes than the heavily edited Google CRLSet.
>>=20
>> There is still a powerful case for short lived certificates. But the
>> minimum feasible expiry interval for short lived certs is 48 hours.
>> Using a compressed CRL in combination with short lived certs would
>> allow the vulnerability window to be reduced to minutes.
>>=20
>>=20
>> We are of course aware that deployment will require a licensing regime
>> that meets the need of all parties including competing CAs, open
>> source software providers, etc. However lacking an existing licensing
>> regime for the rights holder (if indeed any are granted), I thought it
>> best to bring this to people's attention first.
>=20
> Are you saying FRAND or something else?
>=20
>>=20
>> The nature of the invention is such that not applying for a patent
>> would open the possibility that someone else might make a claim as has
>> happened to me on numerous other occasions. In the past five years
>> over $50 million has been spent on defending against such patent
>> claims.
>>=20
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>=20
>=20
>=20
> --=20
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin


From nobody Mon Oct 13 14:54:40 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCD61A0290 for ; Mon, 13 Oct 2014 14:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovU_v42pBmrM for ; Mon, 13 Oct 2014 14:54:36 -0700 (PDT)
Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04261A0231 for ; Mon, 13 Oct 2014 14:54:36 -0700 (PDT)
Received: by mail-oi0-f53.google.com with SMTP id v63so14169632oia.26 for ; Mon, 13 Oct 2014 14:54:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uaYUP/0Y6tTxknX9pBmw4G08shJIe4mksbkV9c++xRs=; b=f+3uEoRGmfPmZLbuM58K8XzCoUu7T/7PizyHToMWoGEB6+eOLwOp5RGF41S4HQG8Kc rcLMFyT8GOcbTq3NgBPDebd4x6nlIOHOTO53sEibaT43K0+dj7CynHeVJQofQwoQJP5Y 1y1NIsPJssMzgr+UI/gvTcGicFCDXZnXlOERP7fZPd8ph0ZHtpEQhvLd6bxCyI5jKxYa /wP0xfKc0UnjiepzC5ZTiHn5RSeq+JKdJHJjX+u7WJse3dUUaskGJwX29fm58aDKC0iM m79A/+tXqqzKzPB9TJxYTXuvTAuWpwiJC2hZIagCDDbPLal6YcpEh6hwrgdSntmbLC6M lE0Q==
X-Gm-Message-State: ALoCoQnmuIdtfvmRJvlVHGNHjAc89aF1mI8vY5zUvji7j2AWC/BzyGIIHW4TSOlS6MeF3F6+RT4h
MIME-Version: 1.0
X-Received: by 10.182.163.20 with SMTP id ye20mr1101022obb.16.1413237276144; Mon, 13 Oct 2014 14:54:36 -0700 (PDT)
Received: by 10.76.102.40 with HTTP; Mon, 13 Oct 2014 14:54:36 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>          
Date: Mon, 13 Oct 2014 14:54:36 -0700
Message-ID: 
From: Brian Smith 
To: Bodo Moeller 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zWRplO3y0IBtJdE-2j7O98p2ptA
Cc: "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Oct 2014 21:54:39 -0000

On Fri, Oct 10, 2014 at 10:07 PM, Brian Smith  wrote:
> There are four cases to consider:
>
> CASE 1: Client included the TLS_FALLBACK_SCSV, server forgot session
> state when it was upgraded. The result is an inappropriate_fallback
> alert.
>
> CASE 2: Client included the TLS_FALLBACK_SCSV, server (magically!!!)
> retained the session state across the server software upgrade. The
> result is an inappropriate_fallback alert.

There's an important thing to note about these two cases: They only
apply when the server is, or recently was, TLS intolerant. That is,
the client did a non-secure fallback due to TLS intolerance, then the
server was upgraded to support the TLS_FALLBACK_SCSV and/or a higher
version of TLS, and then the inappropriate_fallback is sent. If the
server wasn't already TLS intolerant, then CASE 1 and CASE 2 won't
happen. Thus, I think it is better to say tat clients MUST send the
TLS_FALLBACK_SCSV in the ClientHello whenever they decrease
ClientHello.client_version due to their TLS intolerance logic.

Also, the draft fails to state something that is obvious to us, but
which is better to state explicitly: The server needs to ensure it
isn't version intolerant, or else adding support for the
TLS_FALLBACK_SCSV will cause the server to stop working.

There are several non-obvious reasons why a server might seem like it
is "version intolerant" or "extension intolerant" even though it
generally supports version negotiation and generally parses extensions
correctly:

* I have seen modern servers act like they are "TLS intolerant" when
OCSP stapling is enabled and the server's certificate doesn't contain
an OCSP AIA URI. The fallback to SSL 3.0 "works" for them because
browsers stop sending the status_request extension. However, the
server actually does the version negotiation correctly, modulo this
OCSP stapling bug. The best solution to this is to get a new
certificate that has the OCSP AIA URI in it.

* I have seen some servers (e.g. from Cisco) that don't like certain
orderings of TLS extensions (especially the new padding extension).
Again, non-secure fallback to SSL 3.0 "works" for them because no
extensions get sent in the ClientHello. But, the servers actually get
the version negotiation correct, modulo this buggy extension handling.
The solution to this is to upgrade to the version of the server
software that Cisco hasn't released yet(!). (And, browsers should
probably find a workaround for this issue. See
https://bugzilla.mozilla.org/show_bug.cgi?id=998135#c11.)

* I have seen some servers where the hostname-specific TLS
configuration is broken, but where the generic non-host-specific
configuration works. These servers appear to be TLS intolerant because
they try to use the hostname-specific TLS configuration when the SNI
extension is given, and fail due to it being broken. When the browser
downgrades to SSL 3.0, the non-hostname-specific configuration is
picked up, and the handshake succeeds. Thus, the problem isn't in the
server's TLS stack's version engotiatoin at all, but rather in the web
server's configuration file. The solution to this problem is to fix
the fix the configuration file.

These types of issues, and other similar ones, need to be accounted
for when deploying TLS_FALLBACK_SCSV on the server. Because these
issues are relatively easy to fix, and relatively rare, the existence
of these issues shouldn't stop any server software vendor from
deploying TLS_FALLBACK_SCSV and enabling it by default. But, people
should be aware of these issues when diagnosing surprises.

Cheers,
Brian


From SRS0=V2Ir=7E=acm.org=bmoeller@srs.kundenserver.de  Mon Oct 13 16:47:19 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06ECB1A1A00 for ; Mon, 13 Oct 2014 16:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.714
X-Spam-Level: 
X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Gcb7doooE-L for ; Mon, 13 Oct 2014 16:47:17 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339A51A008B for ; Mon, 13 Oct 2014 16:47:17 -0700 (PDT)
Received: from mail-yh0-f46.google.com (mail-yh0-f46.google.com [209.85.213.46]) by mrelayeu.kundenserver.de (node=mreue006) with ESMTP (Nemesis) id 0M4gG1-1YNI3L35iv-00z2LZ; Tue, 14 Oct 2014 01:47:15 +0200
Received: by mail-yh0-f46.google.com with SMTP id f73so4045596yha.5 for ; Mon, 13 Oct 2014 16:47:12 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.228.33 with SMTP id e31mr2548001yhq.56.1413244032572; Mon, 13 Oct 2014 16:47:12 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Mon, 13 Oct 2014 16:47:12 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>          
Date: Tue, 14 Oct 2014 01:47:12 +0200
Message-ID: 
From: Bodo Moeller 
To: "" 
Content-Type: multipart/alternative; boundary=001a11c231fc8ae5850505568456
X-Provags-ID: V02:K0:iTgc4hdTCunewPz+RYxzNPssjsRxEcZpld53/XFnhMv Yd15Ccsdd9qUUHeymAro62hAeXfO22A0zoODxc3TIB/duY06FO WBuejyGYsTGBo/RZhG2C0IFVQ4Ji5uvjTBwqqgU96UGxL2j4PI f2VmxsHbu0Nfe2tE1CJPeda02NAsf5Hib39ZT7IpY4fA1duHJf IrKcPtQyGBk6QdOftB9vvbxH+PG2XLJrRUeWGwtA2ianVeKU8y Cj0wHp6AgYhcmB01p9HqNxnQBiPgxtugNrOCjTmXDSwbzfwhhH +IYmIF3v0QY0i/N/VCcsAj3TEm1L4PZiIX4K147SxJB04rb9/l qCWajF9X6n4q5CGvM6cvFAAfwDK2Xa9uJFr1MeD6I87HLaF1ak CQeMF5nBnuc6p2Fuvvyy030K39A6zWhIrVKleDQtlAYv/Leuv1 upOxt
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DW9fK7NdzlrIFqqWxPeu5HkalBM
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Oct 2014 23:50:07 -0000

--001a11c231fc8ae5850505568456
Content-Type: text/plain; charset=UTF-8

Brian Smith :

[...]

> 3. Server is upgraded to support TLS 1.2 or higher.
> 4. Client attempts to handshake with client_version == TLS 1.1 and a
> resumed session ticket.
>
> There are four cases to consider:
>
[...]

> CASE 3: Client did not include the TLS_FALLBACK_SCSV, the server
> forgot session state when it was upgraded. The server starts a new TLS
> 1.1 session. Thus, the downgrade protection mechanism has failed to
> prevent a version downgrade.
>

Right, this is the most problematic case. Resuming a session using the old
protocol version (if the server still recognizes that session) is one
thing, but using the old version for a new session is another.

However, this issue really just follows from the relevant language in the
TLS RFCs: "Whenever a client already knows the highest protocol version
known to a server (for example, when resuming a session), it SHOULD
initiate the connection in that native protocol." If the client follows
these directions, using the old protocol version even in case the server
gets upgraded is expected.


> Previously I'd assumed you'd want to keep "normal" behavior (simply
> continue
> > to use the previous protocol version), but I don't see a compelling
> reason
> > for the specification to prescribe that to clients.
>
> Doing that also allows version downgrade to succeed inappropriately in
> the case where the server's capabilities were improved during the
> lifetime of a session cached by a client.
>
> I think the best solution is to take my original suggestion (i.e. keep
> the current logic, but make it more clear),


Now I'm a bit confused. If you consider that consequence (using the old
version if server capabilities have improved since) "improper", why do you
suggest keeping the current logic?




> I think it is realistic to expect that servers that implement the
> inappropriate_fallback logic to implement at least TLS 1.2 (or at
> least TLS 1.1),


I'm not so sure -- the TLS_FALLBACK_SCSV mechanism by design works equally
well with TLS 1.0 and can be easily retrofitted at least in principle.
Thus, to allow essentially *every* implementation to benefit from the SCSV,
I wouldn't want to require any higher version.

Boo

--001a11c231fc8ae5850505568456
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Bria=
n Smith <brian@briansmith.org>:

[.=
..]=C2=A0

3. Server is upgraded to support TLS 1.2 or higher.

4. Client attempts to handshake with client_version =3D=3D TLS 1.1 and a
resumed session ticket.



There are four cases to consider:
[...]=C2=A0

CASE 3: Client did not include the TLS_FALLBACK_SCSV, the server

forgot session state when it was upgraded. The server starts a new TLS

1.1 session. Thus, the downgrade protection mechanism has failed to

prevent a version downgrade.

Right, thi=
s is the most problematic case. Resuming a session using the old protocol v=
ersion (if the server still recognizes that session) is one thing, but usin=
g the old version for a new session is another.

Ho=
wever, this issue really just follows from the relevant language in the TLS=
 RFCs: "Whenever a client already knows the highest protocol version k=
nown to a server (for example, when resuming a session), it SHOULD initiate=
 the connection in that native protocol." If the client follows these =
directions, using the old protocol version even in case the server gets upg=
raded is expected.



> Previously I'd assumed you'd want to keep "normal" b=
ehavior (simply continue

> to use the previous protocol version), but I don't see a compellin=
g reason

> for the specification to prescribe that to clients.



Doing that also allows version downgrade to succeed inappropriately =
in

the case where the server's capabilities were improved during the

lifetime of a session cached by a client.



I think the best solution is to take my original suggestion (i.e. keep

the current logic, but make it more clear),

Now I'm a bit confused. If you consider that consequence (using the ol=
d version if server capabilities have improved since) "improper",=
 why do you suggest keeping the current logic?

=C2=A0

I think it is realistic to expect that servers that implement the

inappropriate_fallback logic to implement at least TLS 1.2 (or at

least TLS 1.1),

I'm not so sure -- the =
TLS_FALLBACK_SCSV mechanism by design works equally well with TLS 1.0 and c=
an be easily retrofitted at least in principle. Thus, to allow essentially =
*every* implementation to benefit from the SCSV, I wouldn't want to req=
uire any higher version.

Boo

<=
/div>


--001a11c231fc8ae5850505568456--


From nobody Mon Oct 13 17:22:07 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D56C1A1A5C for ; Mon, 13 Oct 2014 17:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB1KxlFGo9HP for ; Mon, 13 Oct 2014 17:22:04 -0700 (PDT)
Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EAB21A1A5A for ; Mon, 13 Oct 2014 17:22:04 -0700 (PDT)
Received: by mail-oi0-f50.google.com with SMTP id i138so15122663oig.9 for ; Mon, 13 Oct 2014 17:22:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dEBVCn4Boa5D2mGq3S8+EQRWtAiuWF80qL/X40UKhxo=; b=AqIt5YfOxit/jk15tvbfNpxVFWNgGEdVsF2z21wyybQ2stPqdI90OD5RlDeZBK2a/b HY8+1eI7A7PizffkuNslK58CbBaimWhNSzbASrKyIbXuClxvM1Dw5iOpLeV8tzB6cjbk zt3mbGP8FPeh3DnwlBX1qnm0pkS/Cd1Hmv8D0e5LJxYKTi3Hu4VtkX1UDM95Fwz8g/za eAxXoN2htyYoC8jdWhAU0dke6EEGIzGnLkL9xliWJLKKmOeEEWCBYp2RQy5N+c5v+P7S NxnZn9/klLz2RnPLOXS2QFzRYLKxiZ8nSp5ZJpKZ7mBWGUWISMHjq7FBmfA460BauQFx bXzQ==
X-Gm-Message-State: ALoCoQlLU6tekKGYOBKGfX8rEuTJIxojKGQWgE6Zw+smkU/WjH7duXFC+omlJ1Jf+UinmxkjvENn
MIME-Version: 1.0
X-Received: by 10.202.174.76 with SMTP id x73mr1526945oie.12.1413246123918; Mon, 13 Oct 2014 17:22:03 -0700 (PDT)
Received: by 10.76.102.40 with HTTP; Mon, 13 Oct 2014 17:22:03 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>           
Date: Mon, 13 Oct 2014 17:22:03 -0700
Message-ID: 
From: Brian Smith 
To: Bodo Moeller 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/czq8ZwlQh4fN3zgph4PEMDWwWIs
Cc: "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 00:22:06 -0000

On Mon, Oct 13, 2014 at 4:47 PM, Bodo Moeller  wrote:
> Brian Smith :
>> CASE 3: Client did not include the TLS_FALLBACK_SCSV, the server
>> forgot session state when it was upgraded. The server starts a new TLS
>> 1.1 session. Thus, the downgrade protection mechanism has failed to
>> prevent a version downgrade.
>
> Right, this is the most problematic case. Resuming a session using the old
> protocol version (if the server still recognizes that session) is one thing,
> but using the old version for a new session is another.
>
> However, this issue really just follows from the relevant language in the
> TLS RFCs: "Whenever a client already knows the highest protocol version
> known to a server (for example, when resuming a session), it SHOULD initiate
> the connection in that native protocol." If the client follows these
> directions, using the old protocol version even in case the server gets
> upgraded is expected.

I agree. But, my conclusion is that the TLS specification is wrong,
and that that advice should be dropped from it and ignored by clients,
because it enables this scenerio. I also think that the spec should be
changed to require servers to never resume a session for a version
lower than min(ClientHello.version, ), for similar reasons.

In fact, your draft would be a good place to tell clients that they
SHOULD NOT follow that advice in the TLS specifications.

>> I think the best solution is to take my original suggestion (i.e. keep
>> the current logic, but make it more clear),
>
> Now I'm a bit confused. If you consider that consequence (using the old
> version if server capabilities have improved since) "improper", why do you
> suggest keeping the current logic?

The current logic in your draft says that if the client doesn't
downgrade ClientHello.client_version to equal the version in the
resumed session, then it must send the TLS_DOWNGRADE_SCSV if
ClientHello.client_version is less than the highest version that it
supports. That is the correct logic. The way it is written has made
people think that TLS_DOWNGRADE_SCSV is never supposed to be sent
during resumption handshakes, which is why it is good to clarify it.

>> I think it is realistic to expect that servers that implement the
>> inappropriate_fallback logic to implement at least TLS 1.2 (or at
>> least TLS 1.1),
>
> I'm not so sure -- the TLS_FALLBACK_SCSV mechanism by design works equally
> well with TLS 1.0 and can be easily retrofitted at least in principle. Thus,
> to allow essentially *every* implementation to benefit from the SCSV, I
> wouldn't want to require any higher version.

OK.

Cheers,
Brian


From SRS0=XkVJ=7F=acm.org=bmoeller@srs.kundenserver.de  Mon Oct 13 18:08:48 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863491A1A7A for ; Mon, 13 Oct 2014 18:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.714
X-Spam-Level: 
X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8AyGQRm5vB5 for ; Mon, 13 Oct 2014 18:08:43 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2AFC1A1A73 for ; Mon, 13 Oct 2014 18:08:42 -0700 (PDT)
Received: from mail-yh0-f45.google.com (mail-yh0-f45.google.com [209.85.213.45]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0MT92U-1XlzIj2kmU-00SAF8; Tue, 14 Oct 2014 03:08:35 +0200
Received: by mail-yh0-f45.google.com with SMTP id b6so4081123yha.4 for ; Mon, 13 Oct 2014 18:08:32 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.42.165 with SMTP id j25mr2229907yhb.130.1413248912366; Mon, 13 Oct 2014 18:08:32 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Mon, 13 Oct 2014 18:08:32 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>            
Date: Tue, 14 Oct 2014 03:08:32 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c2009866a632050557a75e
X-Provags-ID: V02:K0:67XVc2kfy5MnmlFqbEZM590uY7MXS6dtSiisFRw5ISV 30pSBx8qIU+AajsQKhazhQreQySKNKu2Y0SDbjEyrorOC4QR9O ea8wjsR4ReoIILMnsr4X8WnHkMuaTp6xeAXCloJbj+oetOApw3 uFCEPTPYeCwQknBKZuI1jsfnnmwd0Wg++8nSNn967KFF8CKax8 /sZEJ77WBoxMDHa0tr60yM2wcHH540gsSdFr0gzWX1GzpUO7/9 eEqlITKI95dGPY5HhUoCpeDI6f7IZeoVpGwOicQGIXTLNrDOK4 gvjI6Op0qdVaDnvS9bdFAuZvebDwFgr7tl/zVBmjrGC65TzV3W EGvC0efiuQegOPoE29fq8dI2iZgOz7eyLZORV/TRJeAcabH3cH t8IgeRVhY48RlDH8yni7I9piwrdOIyyYHcFgRICGgRA1knv0eR sYGmA
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rwf3mhTnTpnJhqXcTL1-uCOpHFE
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 01:10:21 -0000

--001a11c2009866a632050557a75e
Content-Type: text/plain; charset=UTF-8

>
> > However, this issue really just follows from the relevant language in the
> > TLS RFCs: "Whenever a client already knows the highest protocol version
> > known to a server (for example, when resuming a session), it SHOULD
> initiate
> > the connection in that native protocol." If the client follows these
> > directions, using the old protocol version even in case the server gets
> > upgraded is expected.
>


> I agree. But, my conclusion is that the TLS specification is wrong,
>

Got it; sorry for being slow.

Here's one way to write that.

"If a client sends a ClientHello.client_version containing a lower value
than the latest (highest-valued) version supported by the client, it SHOULD
include the TLS_FALLBACK_SCSV cipher suite value in
ClientHello.cipher_suites. (...)

Sometimes, a client assuming that it already knows the highest protocol
version supported by a server (such as when resuming a session) may
initiate the connection in that native protocol as per Appendix E.1 of
[RFC5246]. In this situation, as an exception to the above, the client MUST
NOT include TLS_FALLBACK_SCSV in ClientHello.cipher_suites (unless it
downgrades ClientHello.client_version further in additional connection
attempts), since server-side support of protocol versions may have changed
since the previous connection.

(To avoid perpetuating use of an earlier protocol version if the server in
question actually does get updated, such clients SHOULD time out knowledge
of the highest protocol version supported by the server. Also, any such
knowledge MUST be forgotten if the server ever sends an
inappropriate_fallback alert.)"

Bodo

--001a11c2009866a632050557a75e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


> However, this issue really just follows =
from the relevant language in the

> TLS RFCs: "Whenever a client already knows the highest protocol v=
ersion

> known to a server (for example, when resuming a session), it SHOULD in=
itiate

> the connection in that native protocol." If the client follows th=
ese

> directions, using the old protocol version even in case the server get=
s

> upgraded is expected.
=C2=A0

I agree. But, my conclusion is that the TLS specification is wrong,<=
br>

Got it; sorry for being slow.

Here's one way to write that.

=
"If a client sends a ClientHello.client_version containing a lower val=
ue than the latest (highest-valued) version supported by the client, it SHO=
ULD include the TLS_FALLBACK_SCSV cipher suite value in ClientHello.cipher_=
suites. (...)

Sometimes, a client assuming tha=
t it already knows the highest protocol version supported by a server (such=
 as when resuming a session) may initiate the connection in that native pro=
tocol as per Appendix E.1 of [RFC5246]. In this situation, as an exception =
to the above, the client MUST NOT include TLS_FALLBACK_SCSV in ClientHello.=
cipher_suites (unless it downgrades ClientHello.client_version further in a=
dditional connection attempts), since server-side support of protocol versi=
ons may have changed since the previous connection.

(To avoid perpetuating use of an earlier protocol version if the server i=
n question actually does get updated, such clients SHOULD time out knowledg=
e of the highest protocol version supported by the server. Also, any such k=
nowledge MUST be forgotten if the server ever sends=C2=A0an inappropriate_fallback alert.)=
"

Bodo


--001a11c2009866a632050557a75e--


From nobody Wed Oct 15 01:17:14 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94ED11A04BA for ; Wed, 15 Oct 2014 01:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwCAFLTIPDMy for ; Wed, 15 Oct 2014 01:17:11 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432FC1A0470 for ; Wed, 15 Oct 2014 01:17:11 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9F8H9ni009943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 15 Oct 2014 04:17:09 -0400
Received: from oldenburg.str.redhat.com (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9F8H6Wf019672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 15 Oct 2014 04:17:08 -0400
Message-ID: <543E2D81.1050700@redhat.com>
Date: Wed, 15 Oct 2014 10:17:05 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
In-Reply-To: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jISXgrWVuTZaen_aEyAuxhauU_o
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 08:17:12 -0000

On 09/26/2014 06:00 AM, Joseph Salowey (jsalowey) wrote:
> This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your comments to the list by Friday, October 17, 2014.

I'm strongly against this proposal.  It severely punishes those who have 
correctly implemented the protocol all along by forcing them to upgrade 
their code base, for the benefit of those who fail to interoperate (or 
who want to interoperate with those who fail).

We need to get rid of broken implementation, not cater to them 
indefinitely.  With this mindset of unlimited workarounds, no protocol 
versioning mechanism (including the one proposed here) will ever work 
securely because implementations will be forced by overriding concerns 
to ignore protocol failures, against better judgment.

-- 
Florian Weimer / Red Hat Product Security


From nobody Wed Oct 15 01:50:22 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4031A19E4 for ; Wed, 15 Oct 2014 01:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbUORperIYkq for ; Wed, 15 Oct 2014 01:50:17 -0700 (PDT)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345B61A0AFE for ; Wed, 15 Oct 2014 01:50:17 -0700 (PDT)
Received: by mail-pd0-f178.google.com with SMTP id y10so874397pdj.37 for ; Wed, 15 Oct 2014 01:50:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NFLoKTQ62TYuDKOLs+ymZ+wb4VnSMmqjLqupX1feZ5w=; b=JMetfeB8+HoihUINwHBb3NeroDB0vJrzIZZno4FrCkxMh9aXlOW4xUyKeUFOcwEBI3 P/iynIhQita6cB3OePZUlhU6wtebaWEeWumc6TAB0AbVb20dp8jttGfWAYt51aBjiEl2 cIL0qcctem+Rthqe4JAi1+fbyjl0t2DYNgvzwrv+PzVv/fSZtFdiW/Z3gkYRuvl93Oy2 8hpmtbU+d1xq//RUD+foeb/M+HvQ63gsg8XCJP28eUUerlKCm7hN5WWAWZvA98M46qjr /SRQY37RMyYqoZaC7a/CPk58rAilSrw0ebuHmpfakTgiLAxcWyM2TZei6c6rYGH5DHPi rHdw==
X-Received: by 10.66.65.162 with SMTP id y2mr10392320pas.57.1413363016879; Wed, 15 Oct 2014 01:50:16 -0700 (PDT)
Received: from [10.0.1.6] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id a12sm2469153pdm.64.2014.10.15.01.50.14 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 01:50:15 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Fabrice 
X-Mailer: iPhone Mail (12B411)
In-Reply-To: <543E2D81.1050700@redhat.com>
Date: Wed, 15 Oct 2014 01:50:13 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com>
To: Florian Weimer 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cuzAPqv0ouBPlgjz7jbD_FRkkfI
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 08:50:21 -0000

> On Oct 15, 2014, at 01:17, Florian Weimer  wrote:
>=20
>> On 09/26/2014 06:00 AM, Joseph Salowey (jsalowey) wrote:
>> This is an announcement for the working group last call for draft-ietf-tl=
s-downgrade-scsv-00.  Please review the document and send your comments to t=
he list by Friday, October 17, 2014.
>=20
> I'm strongly against this proposal.  It severely punishes those who have c=
orrectly implemented the protocol all along by forcing them to upgrade their=
 code base, for the benefit of those who fail to interoperate (or who want t=
o interoperate with those who fail).

I don't see how this force anybody to implement this or punish anybody who d=
oesn't.=20

Even if the majority of implementations were to implement this, they would s=
till interoperate with the ones that don't implement it.


>=20
> We need to get rid of broken implementation, not cater to them indefinitel=
y.  With this mindset of unlimited workarounds, no protocol versioning mecha=
nism (including the one proposed here) will ever work securely because imple=
mentations will be forced by overriding concerns to ignore protocol failures=
, against better judgment.

Unfortunately, interop with broken systems is pretty much a requirement in m=
any cases.=20
Without the workarounds such as retry and fallbacks, I believe the adoption o=
f newer, more secure, version of TLS would be even slower. Catering to broke=
n implementation may actually help in the long term, I think.


-- Fabrice=


From SRS0=qaHA=7G=acm.org=bmoeller@srs.kundenserver.de  Wed Oct 15 02:22:58 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEB21A19FA for ; Wed, 15 Oct 2014 02:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N18LF2RwBejU for ; Wed, 15 Oct 2014 02:22:57 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C8E1A19F0 for ; Wed, 15 Oct 2014 02:22:57 -0700 (PDT)
Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0M8iuS-1XSBhS2GGS-00CBsA; Wed, 15 Oct 2014 11:22:54 +0200
Received: by mail-yh0-f54.google.com with SMTP id z6so385785yhz.41 for ; Wed, 15 Oct 2014 02:22:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.231.116 with SMTP id k110mr11744680yhq.127.1413364972258;  Wed, 15 Oct 2014 02:22:52 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 02:22:51 -0700 (PDT)
In-Reply-To: <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>
Date: Wed, 15 Oct 2014 11:22:51 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0160a2741c174a050572adf2
X-Provags-ID: V02:K0:YL8dtShK6Gt3R3tenVT7mbypcRugdsNIbO7vKXZ8O9U wK1QEx/uYbhQpqES9pk4P0mT4JCPK1HbMx8IDYCT8k32RDaL0h AXCVauOgJWRD1122OCIwUsEToCHvjaJgH8FCBVWsxdwY7Po92h UweGoEaKL8qRUHfXNrmXrmdxseKK8hLKMcg3YRCQNjshPJfMVC YhA4dayLnOYGL5oOg0QWBO/iD2Gd9qYoAUTx0CPaNm4IVxZiMt jpIYY/GlssUr38rTt/hFMCnMFQT8KF6uaFySUpm5rEE9Y7LZ+7 rWkxF5A+7C1odGrfE0TpT2z9PvHHOFA6rsx4gUghKNZMYEifiq ZqPpAJGh1br4kWGsLTrv9ptFNVkzjA0pQ92cy2AtFPUjd8yyiw 7vw8KES1Oed5xLZbsMcKeuGLOP5lJV45IiCIOaT5J92znIe0Tp 3QzVg
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-C3owSFLCT4XBRLo8cpjz0mOLoQ
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 09:23:40 -0000

--089e0160a2741c174a050572adf2
Content-Type: text/plain; charset=UTF-8

Note that if your server does not support formally obsolete protocol
versions, TLS_FALLBACK_SCSV support is a no-op.

Otherwise, you're making real-world tradeoffs, and I think
TLS_FALLBACK_SCSV is a reasonable one to make (with minimal server-side
logic to achieve the objective), not "punishment".

Bodo

--089e0160a2741c174a050572adf2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Note that if your server does not support formally obsolet=
e protocol versions, TLS_FALLBACK_SCSV support is a no-op.

Otherwise, you're making real-world tradeoffs, and I think TLS_FALLB=
ACK_SCSV is a reasonable one to make (with minimal server-side logic to ach=
ieve the objective), not "punishment".

B=
odo



--089e0160a2741c174a050572adf2--


From nobody Wed Oct 15 02:25:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813E71A19FA for ; Wed, 15 Oct 2014 02:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.51
X-Spam-Level: 
X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQNaFj3XvvsK for ; Wed, 15 Oct 2014 02:25:29 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 393F71A19F7 for ; Wed, 15 Oct 2014 02:25:29 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 820154753F; Wed, 15 Oct 2014 09:25:28 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 7603247526; Wed, 15 Oct 2014 09:25:28 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 71F7F202C; Wed, 15 Oct 2014 09:25:28 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 15 Oct 2014 05:25:21 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 15 Oct 2014 05:25:21 -0400
From: "Salz, Rich" 
To: Bodo Moeller , "tls@ietf.org" 
Date: Wed, 15 Oct 2014 05:25:17 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/oWbomIAbtPlaOT3SKK6yH/s4qNQAABnzA
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE7E8@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vh0BGOKZJ-trCBAqjWWCP9hZbDE
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 09:25:30 -0000

PiBPdGhlcndpc2UsIHlvdSdyZSBtYWtpbmcgcmVhbC13b3JsZCB0cmFkZW9mZnMsIGFuZCBJIHRo
aW5rIFRMU19GQUxMQkFDS19TQ1NWIGlzIGEgcmVhc29uYWJsZSBvbmUgdG8gbWFrZSAod2l0aCBt
aW5pbWFsIHNlcnZlci1zaWRlIGxvZ2ljIHRvIGFjaGlldmUgdGhlIG9iamVjdGl2ZSksIG5vdCAi
cHVuaXNobWVudCIuDQoNCkFncmVlZC4gIEFuZCBpbiBmYWN0LCB0aGUgcXVhbGl0eSBvZiB0aGUg
cHJvdG9jb2wgaW1wbGVtZW50YXRpb24gZG9lc24ndCBlbnRlciBpbnRvIGl0LiAgSXQncyBtb3Jl
IGFib3V0IHRoZSBxdWFsaXR5IG9mIHRoZSBwcm90b2NvbC4NCg0KCS9yJA0KDQotLSAgDQpQcmlu
Y2lwYWwgU2VjdXJpdHkgRW5naW5lZXIsIEFrYW1haSBUZWNobm9sb2dpZXMNCklNOiByc2FsekBq
YWJiZXIubWUgVHdpdHRlcjogUmljaFNhbHoNCg0K


From nobody Wed Oct 15 04:04:08 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69321A1A87 for ; Wed, 15 Oct 2014 04:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxGHG7eADq_f for ; Wed, 15 Oct 2014 04:04:03 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2471A1A86 for ; Wed, 15 Oct 2014 04:04:03 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FB3xid010600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 15 Oct 2014 07:04:00 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FB3vi9015177 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2014 07:03:59 -0400
Message-ID: <1413371037.15961.26.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Fabrice 
Date: Wed, 15 Oct 2014 13:03:57 +0200
In-Reply-To: <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eet40y8kHzL4Bm8InB6_Wvshucc
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 11:04:06 -0000

On Wed, 2014-10-15 at 01:50 -0700, Fabrice wrote:
> >> This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your comments to the list by Friday, October 17, 2014.
> > I'm strongly against this proposal.  It severely punishes those who have correctly implemented the protocol all along by forcing them to upgrade their code base, for the benefit of those who fail to interoperate (or who want to interoperate with those who fail).
> I don't see how this force anybody to implement this or punish anybody who doesn't. 

Of course, but then what is the point of standardizing it? In any case,
I don't believe how adding support for this extension on every
implementation (in order for the protection to matter) is easier than
fixing the few broken servers that don't properly do version
negotiation. I believe there is little point for this protocol
extension, given that the work arounds for the applications that use
non-standard version negotiation are very straightforward (disable SSL
3.0).

regards,
Nikos



From nobody Wed Oct 15 05:01:56 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4310B1A1B51 for ; Wed, 15 Oct 2014 05:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqoDsOpFNT3J for ; Wed, 15 Oct 2014 05:01:53 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED211A1B5D for ; Wed, 15 Oct 2014 05:01:52 -0700 (PDT)
Received: from pc.my-domain (tmo-102-72.customers.d1-online.com [::ffff:80.187.102.72]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 15 Oct 2014 14:01:49 +0200 id 0000000000000091.00000000543E622D.00006177
Date: Wed, 15 Oct 2014 14:01:58 +0200
From: Hanno =?ISO-8859-1?B?QvZjaw==?= 
To: tls@ietf.org
Message-ID: <20141015140158.41a1faf8@pc.my-domain>
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com> 
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-24951-1413374510-0001-2"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9WG12Bb8d2vGUqem-DbbyfEwHTQ
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 12:01:55 -0000

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zucker.schokokeks.org-24951-1413374510-0001-2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Wed, 15 Oct 2014 11:22:51 +0200
schrieb Bodo Moeller :

> Note that if your server does not support formally obsolete protocol
> versions, TLS_FALLBACK_SCSV support is a no-op.
>=20
> Otherwise, you're making real-world tradeoffs, and I think
> TLS_FALLBACK_SCSV is a reasonable one to make (with minimal
> server-side logic to achieve the objective), not "punishment".

Can you quantify that tradeoff? How many devices are there really out
there that would break? I'd like to have this discussions with
hard numbers.

I mean we are not talking about legacy compatibility. We're talking
about compatibility with broken stuff.

I want to weight my voice in support of Florian. What we have here is
an out-of-protocol workaround with security and compatibility
implications and a solution that adds another workaround on top of that.

To compare the two:

One solution (keeping downgrade-workarounds and add SCSV):
* Compatiblity with a likely small number (but I'm waiting for hard
  numbers here) of broken legacy hard/software
* Add more complexity to TLS
* Support people who deploy broken stuff, punish people who support
  completely correct configs

Other solution (remove downgrade-workarounds):
* Break some compatiblity with broken devices
* Reduce complexity of TLS in browsers
* Support people who deploy correct implementations, punish people who
  support broken stuff

I think the argument is clearly in favor of the latter solution unless
you have some very good counterarguments.

cu,
--=20
Hanno B=F6ck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

--=_zucker.schokokeks.org-24951-1413374510-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJUPmI2AAoJEKWIAHK7tR5C+JIQAJt99WwXUQQNu4L0F8AnVYdR
Ms6sfJv683m1y4JpyTyiDM+6oJAFoHeCu1Xyp8uhpPYu2r7gzRa/HHjegbiwkQdI
IfffccWJpbsVzePqOiph0ciLEZ5V438fbWNgAH7Gv1OXQKxwkrASd1BkJ1hSYe28
nX7W40WzieEUtQ4gQoFgkv5dt3Lhb7TSSaTecJb36dK9BoR2BbHrkUt4pXfn2boE
tY0o7ZDqvGLERLl70AqJ6c2qNeskBfexvwtn0X6vZaYUNdxssAnWThFjTNJpSsIm
+sJr4TU3YoRob285Bir4a3o7qvBSjs0LgHwKk6ErR73iWzls+Mce0Uu3t5YwSDqv
rnMI9pFzxdxIdcaQf+6XbgTAx6umxjb+c2/fZdHWPqdb6I1i1oPeCF6fWtjBB2Nf
kBBPM4bdUWvbIhupRFaDLIlZGTVmJgC8C6T6o4KzLLvkXD0boN6LWF+Rl8QY4935
vyGeKVLcVmRXEJ2pboYH36h2UWJs1rusbzKJnPTfbM40kM2Jq5dLRNH6AP7EDGxf
lG5sk7KrYLke0ha+Eg2D9O7YsJRMHlV/pQv7gBtI6v5IWbb41tUBVVNj/pVk0RoB
gOs9HK1CrzLbJHfEtuEGwrDo10QGxS+P5OsxocfpPab3liqJFUVjq6+Pvq8B9udd
PnOPGYgju3uyIrbj7MRk
=Z19v
-----END PGP SIGNATURE-----

--=_zucker.schokokeks.org-24951-1413374510-0001-2--


From nobody Wed Oct 15 05:02:30 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2AE1A1B65 for ; Wed, 15 Oct 2014 05:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vktTmXASplzo for ; Wed, 15 Oct 2014 05:02:26 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D411A1B68 for ; Wed, 15 Oct 2014 05:02:26 -0700 (PDT)
Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) by mrelayeu.kundenserver.de (node=mreue007) with ESMTP (Nemesis) id 0M6t73-1YQ2QK31C1-00wkeN; Wed, 15 Oct 2014 14:02:22 +0200
Received: by mail-yk0-f173.google.com with SMTP id 200so478748ykr.32 for ; Wed, 15 Oct 2014 05:02:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.22.228 with SMTP id t64mr3355158yht.164.1413374539512; Wed, 15 Oct 2014 05:02:19 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 05:02:19 -0700 (PDT)
In-Reply-To: <1413371037.15961.26.camel@dhcp-2-127.brq.redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com> <1413371037.15961.26.camel@dhcp-2-127.brq.redhat.com>
Date: Wed, 15 Oct 2014 14:02:19 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=e89a8f642a985cc5dc050574e786
X-Provags-ID: V02:K0:US4RBUtRK6vi+4pj5d7FygX/X2/J1gIWRCDn4BX1GI3 Hs4k+5HY5rflka+B0A8JRszxxjqf9k3unY+NYV2xQsyNl5e8KP VUjCtXdGDYub/6dyE9U/hpt9SjApUhFwquMYdqWBJBjJKi7PLb Sxq39KayTwID90dV8/j8p2hFrEaZOdnNFMB+00YeaTV5HXHQtq JSiSslb3U5jFkbqLU7F2LSiBrhAx1LLByen6SDa0AI2sRVvnqc x3mpcBcQ3foYrlMp57M06P/XU91aH6nrDEqBAlmn0N651Bzu87 bb6PtCZwqv8a0hkz4ZYf2nTi2XgUkPooj3jP87UdQ02GVuB3r/ 7oDXyaXRbMZuMUSw543a/1jGpjZPuznxOJAQT32phyFgnSAMYb 4/AT7dWcJuaDEec665i0VRR6dW2YKa5+V/MeIGA+7oI+O9Cpko 8HB/b
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ObbjJ0ylhE-ecDholQKPYxNvxS0
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 12:02:28 -0000

--e89a8f642a985cc5dc050574e786
Content-Type: text/plain; charset=UTF-8

Nikos Mavrogiannopoulos :

In any case,
> I don't believe how adding support for this extension on every
> implementation (in order for the protection to matter) is easier than
> fixing the few broken servers that don't properly do version
> negotiation.


Getting *every* implementation updated certainly is not easier. The
difference is that you don't have to -- the SCSV can be used (and indeed
*has* successfully been used) to protect against potential attacks when
connecting to servers that have been updated, while still allowing clients
to have kludgey interoperability with broken servers if they'd rather have
(potentially lower-security) connections to those than no interoperability
at all. As you know, browser implementors have widely seen a need for this.

At the same time, I completely agree that the broken servers must be shut
down too; but it's not either-or.


I believe there is little point for this protocol
> extension, given that the work arounds for the applications that use
> non-standard version negotiation are very straightforward (disable SSL
> 3.0).


Note that the SCSV is not tied to a particular protocol version. Also, we
see the step of disabling SSL 3.0 taken as a concrete *response* (while
still allowing downgrades to any TLS versions that clients may be willing
to fall back to). The SCSV can be used to protect against downgrade attacks
in general, *preventively*.

So unless you disables all protocol versions below TLS 1.2 now, supporting
the SCSV has demonstrable advantages in protecting against potential
attacks.

Bodo

--e89a8f642a985cc5dc050574e786
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Niko=
s Mavrogiannopoulos <nmav@redhat.com>:

In any case,

I don't believe how adding support for this extension on every

implementation (in order for the protection to matter) is easier than

fixing the few broken servers that don't properly do version

negotiation.

Getting *every* implementation=
 updated certainly is not easier. The difference is that you don't have=
 to -- the SCSV can be used (and indeed *has* successfully been used) to pr=
otect against potential attacks when connecting to servers that have been u=
pdated, while still allowing clients to have kludgey interoperability with =
broken servers if they'd rather have (potentially lower-security) conne=
ctions to those than no interoperability at all. As you know, browser imple=
mentors have widely seen a need for this.

At the s=
ame time, I completely agree that the broken servers must be shut down too;=
 but it's not either-or.


 I believe there is little point for this protocol

extension, given that the work arounds for the applications that use

non-standard version negotiation are very straightforward (disable SSL

3.0).

Note that the SCSV is not tied t=
o a particular protocol version. Also, we see the step of disabling SSL 3.0=
 taken as a concrete *response* (while still allowing downgrades to any TLS=
 versions that clients may be willing to fall back to). The SCSV can be use=
d to protect against downgrade attacks in general, *preventively*.

So unless you disables all protocol versions below T=
LS 1.2 now, supporting the SCSV has demonstrable advantages in protecting a=
gainst potential attacks.

Bodo

<=
/div>


--e89a8f642a985cc5dc050574e786--


From nobody Wed Oct 15 05:20:04 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957331A1F04 for ; Wed, 15 Oct 2014 05:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level: 
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7oW0zSn5X7l for ; Wed, 15 Oct 2014 05:20:02 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id EF9561A1C06 for ; Wed, 15 Oct 2014 05:20:01 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 69DF5474BD; Wed, 15 Oct 2014 12:20:01 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5C7B5474A3; Wed, 15 Oct 2014 12:20:01 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 4D2E22026; Wed, 15 Oct 2014 12:20:01 +0000 (GMT)
Received: from usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 15 Oct 2014 08:20:00 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Wed, 15 Oct 2014 08:20:00 -0400
From: "Salz, Rich" 
To: =?iso-8859-1?Q?Hanno_B=F6ck?= , "tls@ietf.org" 
Date: Wed, 15 Oct 2014 08:19:59 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/ob9T+EKF5MawEQHSUyQfVMep1kgAACyuA
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <20141015140158.41a1faf8@pc.my-domain>
In-Reply-To: <20141015140158.41a1faf8@pc.my-domain>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bS0tYTY8LXdtVOR3RRo4n9_0A_A
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 12:20:02 -0000

> Can you quantify that tradeoff? How many devices are there really out the=
re
> that would break? I'd like to have this discussions with hard numbers.

We (Akamai) see less than 1% SSLv2 and SSLv3 traffic globally and it's conc=
entrated to a few particular clients.  Those clients are important to some =
customers. They want modern browsers to be protected, by not falling back t=
o SSLv3, but they don't want to cut off those legacy clients.  SCSV fallbac=
k solves that problem. It also will solve a problem when some browsers try =
to use TLS 1.3 but servers haven't been updated.

Does that help?=20

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Wed Oct 15 05:28:40 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4F31A1F70 for ; Wed, 15 Oct 2014 05:28:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6ErXB0djp3W for ; Wed, 15 Oct 2014 05:28:38 -0700 (PDT)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3651A00C6 for ; Wed, 15 Oct 2014 05:28:38 -0700 (PDT)
Received: by mail-ig0-f174.google.com with SMTP id a13so17227179igq.13 for ; Wed, 15 Oct 2014 05:28:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N7IjLbnR1Jj8EKgOhXWWF58MT8oWeFUESnnzFMBoQjk=; b=W6ghkU4ujEUSKHlaa1xrVgxxizGm4ulH/giEIIc4xo9obrIoweLQDfImKbJ3tYVvUM jFKKYTLji5afWdGtvCjkL7fGa43VBJWxn9EbRYblQ3N51i/S1aQD0obdvhPh8F/2C1RG sTUcv3+nES0dQq+usxlVF/6mF2TNDS3ROfgVgMlh/gjsi4Iwa9KrU9SAK1EhIMCM0YJk 4eEsrjhQ3qrWxkgnP/7Zoc9C0v6z/d6d4MnCQx+4qf6IvNKYQCCX3t0VoXPHhZsGDqGL psYJaK+S9BBlkOl4ZeX/O1J9c6BcYtDZjj+ntaG7Q/ctm1XRMJgTZu7fulsG8uISs43Y S3aA==
MIME-Version: 1.0
X-Received: by 10.42.6.131 with SMTP id a3mr10756902ica.7.1413376117761; Wed, 15 Oct 2014 05:28:37 -0700 (PDT)
Received: by 10.107.10.79 with HTTP; Wed, 15 Oct 2014 05:28:37 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <20141015140158.41a1faf8@pc.my-domain> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com>
Date: Wed, 15 Oct 2014 14:28:37 +0200
Message-ID: 
From: CodesInChaos 
To: "Salz, Rich" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5zrNxxVJekzplRMsQmuUIWk3YTA
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 12:28:39 -0000

I think the question is about the number of buggy servers (and I think
firewalls or proxies) that don't implement version negotiation
correctly and thus cause clients which want to interoperate with them
to do the risky downgrade retry dance.


From nobody Wed Oct 15 05:36:12 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F1E1A6F24 for ; Wed, 15 Oct 2014 05:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.531
X-Spam-Level: 
X-Spam-Status: No, score=-1.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Eq888HXdcTi for ; Wed, 15 Oct 2014 05:36:09 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84CFD1A6F3A for ; Wed, 15 Oct 2014 05:36:06 -0700 (PDT)
Received: from pc (tmo-096-119.customers.d1-online.com [::ffff:80.187.96.119]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 15 Oct 2014 14:36:03 +0200 id 0000000000000081.00000000543E6A33.00001862
Date: Wed, 15 Oct 2014 14:36:11 +0200
From: Hanno =?ISO-8859-1?B?QvZjaw==?= 
To: "Salz, Rich" , "tls@ietf.org" 
Message-ID: <20141015143611.1c7b079b@pc>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <20141015140158.41a1faf8@pc.my-domain> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com>
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-6242-1413376564-0001-2"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Bf9fV-I8bGdBE7itiwBRoas3cMc
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 12:36:11 -0000

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zucker.schokokeks.org-6242-1413376564-0001-2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Wed, 15 Oct 2014 08:19:59 -0400
schrieb "Salz, Rich" :

> We (Akamai) see less than 1% SSLv2 and SSLv3 traffic globally and
> it's concentrated to a few particular clients.  Those clients are
> important to some customers. They want modern browsers to be
> protected, by not falling back to SSLv3, but they don't want to cut
> off those legacy clients.  SCSV fallback solves that problem. It also
> will solve a problem when some browsers try to use TLS 1.3 but
> servers haven't been updated.

That's not really the point we're talking about.
SCSV is as far as I understood not to support SSLv2/3. SSLv3 should be
almost dead after POODLE (and I don't shed a tear).

What SCSV is about is a workaround to a workaround to support
servers that don't support in-protocol-downgrades. I think this has
been called "Protocol version intolerance" in the past (however I think
"protocol version breakage" would be a better term).

So the number I want to see is: How many servers are there that are not
capable of correctly negotiating the SSL/TLS versions they support?

--=20
Hanno B=F6ck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

--=_zucker.schokokeks.org-6242-1413376564-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJUPmo7AAoJEKWIAHK7tR5C2oQQAKSdvMwKoJXG7eAKwhs5Lr8a
HT1eze7mgnwGFLimZz+k+CkvSL7P7AdNXlbunWSQtY5he2KI+7Oce4rqmYURpqET
ENOVDDIwdMoHOIFQrz8IuIRWSHsdxEtNxCGtcAcMm4UIeq7lJXnr9UwWf+ENuYBG
gdFWH5UZkpfagbB2m5b3t7lRGuf6xl39nSgwiIq9xF26sk03pm7Wbun8TYwY6ijU
MDnCLhTAiauEiIAESy6NwdlbOXOPZXI9gh6ohdkYGNQkPbTgsVXmkelLdmtp2/Bt
GgboENJrcfSSbnKeCyCrcUGY0WncM/Dsz9y9LukTCitdl+CS7myy+tF2iNHh0IPl
RmjMkhtEEFaL+VVTsQi0ZHnSSkQDnVkTSm+9UK2NzWl4s9RO65KphN/6G7BfnhBt
pRxjsxdjDgJi0bwSGkpeuaQacZNJf2aadNqbKCb5RKuQ3Mne1J1St0iwCQM2cEgX
FCOD3lgoqyeRAf4rBS1cWJjGnKA7IKJuXN2003IkWho0s/c9zwJ/xjEG8qXAAb9+
hvpILUoQhL+3re82ofRl26AL40/ho4gwlFNO+568JkBqeQIrTmG3qMqCWuBuFoBK
cTNEIHpts3LM3wmgKLNYM5CZEImkJLBjaFdVdHeVsLS64WdbNvz9NuiWVD/QdFK0
6vUKSMG0WH4zV8RM6uqu
=w+L1
-----END PGP SIGNATURE-----

--=_zucker.schokokeks.org-6242-1413376564-0001-2--


From nobody Wed Oct 15 05:43:25 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0B61A01AA for ; Wed, 15 Oct 2014 05:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level: 
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmeZSLne76pc for ; Wed, 15 Oct 2014 05:43:21 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 8718B1A1B63 for ; Wed, 15 Oct 2014 05:43:21 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 07D7748769; Wed, 15 Oct 2014 12:43:21 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id F037A48764; Wed, 15 Oct 2014 12:43:20 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id D86FB9803E; Wed, 15 Oct 2014 12:43:20 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 15 Oct 2014 08:43:20 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 15 Oct 2014 08:43:20 -0400
From: "Salz, Rich" 
To: =?iso-8859-1?Q?Hanno_B=F6ck?= , "tls@ietf.org" 
Date: Wed, 15 Oct 2014 08:43:17 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/odJlR/yYWWmXoTZmhkJVm3LQQ4QAAOHqw
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE85E@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <20141015140158.41a1faf8@pc.my-domain> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com> <20141015143611.1c7b079b@pc>
In-Reply-To: <20141015143611.1c7b079b@pc>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/worB263UZjb1Ci_KYq92_-CJXGg
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 12:43:22 -0000

> So the number I want to see is: How many servers are there that are not
> capable of correctly negotiating the SSL/TLS versions they support?

That's not the question that SCSV is trying to address.

The question is:  how many clients end up using SSLv3 when the could use so=
mething better?

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Wed Oct 15 05:54:36 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711EE1A6F63 for ; Wed, 15 Oct 2014 05:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMbEdMnQFOpo for ; Wed, 15 Oct 2014 05:54:32 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A492C1A6F5D for ; Wed, 15 Oct 2014 05:54:32 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FCsQV3022093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 15 Oct 2014 08:54:26 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FCsOmg020888 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2014 08:54:25 -0400
Message-ID: <1413377664.15961.36.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: "Salz, Rich" 
Date: Wed, 15 Oct 2014 14:54:24 +0200
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <20141015140158.41a1faf8@pc.my-domain> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/slLaEkaFejbFrj52TxuFYq-5NFM
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 12:54:34 -0000

On Wed, 2014-10-15 at 08:19 -0400, Salz, Rich wrote:
> > Can you quantify that tradeoff? How many devices are there really out there
> > that would break? I'd like to have this discussions with hard numbers.
> 
> We (Akamai) see less than 1% SSLv2 and SSLv3 traffic globally and it's concentrated to a few particular clients.  Those clients are important to some customers. They want modern browsers to be protected, by not falling back to SSLv3, but they don't want to cut off those legacy clients.  SCSV fallback solves that problem. It also will solve a problem when some browsers try to use TLS 1.3 but servers haven't been updated.
> Does that help? 

No, it is irrelevant. What matters for this decision are how many TLS
negotiation intolerant servers are out there.

regards,
Nikos



From nobody Wed Oct 15 05:58:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86051A1B23 for ; Wed, 15 Oct 2014 05:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsxgMf-CpYFk for ; Wed, 15 Oct 2014 05:58:14 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 238281A1B15 for ; Wed, 15 Oct 2014 05:58:14 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8A3C0475C6; Wed, 15 Oct 2014 12:58:13 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 71F93475C4; Wed, 15 Oct 2014 12:58:13 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 24C1480047; Wed, 15 Oct 2014 12:58:13 +0000 (GMT)
Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 15 Oct 2014 08:58:12 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 15 Oct 2014 08:58:12 -0400
From: "Salz, Rich" 
To: Nikos Mavrogiannopoulos 
Date: Wed, 15 Oct 2014 08:58:09 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/odyixbLegd/yETsu31VnYwqQp9AAAFbqA
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE876@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <20141015140158.41a1faf8@pc.my-domain> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com> <1413377664.15961.36.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1413377664.15961.36.camel@dhcp-2-127.brq.redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4W8IAyCpwHsG2k7fOYzzfIWriw4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 12:58:15 -0000

PiBObywgaXQgaXMgaXJyZWxldmFudC4gV2hhdCBtYXR0ZXJzIGZvciB0aGlzIGRlY2lzaW9uIGFy
ZSBob3cgbWFueSBUTFMNCj4gbmVnb3RpYXRpb24gaW50b2xlcmFudCBzZXJ2ZXJzIGFyZSBvdXQg
dGhlcmUuDQoNClNvcnJ5LCBJIGRvbid0IGtub3cgd2hhdCB0aGlzIG1lYW5zLg0KDQoNCi0tICAN
ClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlciwgQWthbWFpIFRlY2hub2xvZ2llcw0KSU06IHJz
YWx6QGphYmJlci5tZSBUd2l0dGVyOiBSaWNoU2Fseg0KDQoNCg==


From nobody Wed Oct 15 06:00:09 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63A91A1B7B for ; Wed, 15 Oct 2014 06:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.261
X-Spam-Level: ***
X-Spam-Status: No, score=3.261 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_BACK=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxU3Ux1GfTbj for ; Wed, 15 Oct 2014 06:00:05 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4F51A1B23 for ; Wed, 15 Oct 2014 06:00:05 -0700 (PDT)
Received: from mail-yh0-f48.google.com (mail-yh0-f48.google.com [209.85.213.48]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0MFOmu-1XQ4JS3NWm-00ENBc; Wed, 15 Oct 2014 15:00:03 +0200
Received: by mail-yh0-f48.google.com with SMTP id v1so535432yhn.35 for ; Wed, 15 Oct 2014 05:59:59 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.203.130 with SMTP id f2mr13833753yho.91.1413377999494; Wed, 15 Oct 2014 05:59:59 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 05:59:59 -0700 (PDT)
In-Reply-To: <20141015140158.41a1faf8@pc.my-domain>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <20141015140158.41a1faf8@pc.my-domain>
Date: Wed, 15 Oct 2014 14:59:59 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c2b57497e969050575b5fd
X-Provags-ID: V02:K0:NkwhLpGcIltCNLEXd8tXncdhcdha0DdC22rGSs7B5Uq Nmn6URwm1Jia+3BVuQrpSHAYidz/Q/fhye7SLFQ6jehySQ3ziM gXz1Db/a73bKllYjkJ+jY9VP995hLPC1duFa2zqoYfiKokc1V0 GXxBH7tSqIwMZflZTX2i999PHXPqXVK1YMczmxC+3iHFhe0wm8 UBfkNkoJJeI2sxTH17Dce9fK3ET0zN0QflUMkwwjQR/ELD9+bF 4IgAID1RDeazhgR4sKHgpJehha/ykIS2wrFXyN/v4ameIxV3B1 m9Yg231U33LYPRRcCIJQtqwZUJBGR3ftOe065mtfaWnfpuvDTt KimUqapSOTdpLjVxdb91o/Z6WamN97uOA9BzM7L2r9VZiTPTvw Qeu2E19xtHIri+3AgSLh3XqGM7PwV9ri/wmL4qUPsm13KNYQsE yQSCT
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yKSBqegcBdIO1bfJldc9RuSQRo4
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 13:00:07 -0000

--001a11c2b57497e969050575b5fd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hanno B=C3=B6ck :

Can you quantify that tradeoff? How many devices are there really out
> there that would break? I'd like to have this discussions with
> hard numbers.
>

Finding hard numbers is, well, hard. In general, you find out the whole
picture about what you've broken only after you've broken it.

That doesn't mean that people aren't trying to get good estimates (Ivan
Ristic has done some data collection -- I've include some of his results in
slide 2 of http://www.ietf.org/proceedings/90/slides/slides-90-tls-0.pdf).
However, this doesn't cover other use cases such as an old printer on your
LAN with an SSL 3.0 admin interface.


One solution (keeping downgrade-workarounds and add SCSV):
>
[...]

> Other solution (remove downgrade-workarounds):
>
[...]

> I think the argument is clearly in favor of the latter solution unless
> you have some very good counterarguments.
>

I don't agree with the premise of your reasoning, because these two
approaches are in fact not mutually exclusive. Yes, we should get rid of
downgrade workarounds (browser vendors have been struggling with this for
years). At the same time, the SCSV offers us a general and simple way to
avoid security vulnerabilities when we fail to achieve perfection in that
area.

Less importantly, you've also not considered the complete incentive (or
disincentive, aka "punishment") structure. Disabling the downgrade dance in
one browser could drive that browser's users to a different browser that
"just works" (because it still willingly downgrades itself), which wouldn't
help anyone. In any case, the downgrade dance always punishes broken sites
with bad latency.

Bodo

--001a11c2b57497e969050575b5fd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hann=
o B=C3=B6ck <hanno@hboeck.de>:

Can you quantify that tradeoff? How many devices are =
there really out

there that would break? I'd like to have this discussions with

hard numbers.

Finding hard numbers is, =
well, hard. In general, you find out the whole picture about what you'v=
e broken only after you've broken it.

That doe=
sn't mean that people aren't trying to get good estimates (Ivan Ris=
tic has done some data collection -- I've include some of his results i=
n slide 2 of http://www.ietf.org/proceedings/90/slides/slides-90-tls-0.pdf). However, this doesn't cover other use cases such as an old printer=
 on your LAN with an SSL 3.0 admin interface.


One solution (keeping downgrade-workarounds and add SCSV):
=

[...]=C2=A0

Other solution (remove downgrade-workarounds):
[...]=
=C2=A0

I think the argument is clearly in favor of the latter solution unless

you have some very good counterarguments.

I don't agree with the premise of your reasoning, because these two =
approaches are in fact not mutually exclusive. Yes, we should get rid of do=
wngrade workarounds (browser vendors have been struggling with this for yea=
rs). At the same time, the SCSV offers us a general and simple way to avoid=
 security vulnerabilities when we fail to achieve perfection in that area.<=
/div>

Less importantly, you've also not considered t=
he complete incentive (or disincentive, aka "punishment") structu=
re. Disabling the downgrade dance in one browser could drive that browser&#=
39;s users to a different browser that "just works" (because it s=
till willingly downgrades itself), which wouldn't help anyone. In any c=
ase, the downgrade dance always punishes broken sites with bad latency.
=


Bodo




--001a11c2b57497e969050575b5fd--


From nobody Wed Oct 15 06:41:42 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CE61A6FA7 for ; Wed, 15 Oct 2014 06:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.079
X-Spam-Level: 
X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu-djstXiwM2 for ; Wed, 15 Oct 2014 06:41:41 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50401A6F8C for ; Wed, 15 Oct 2014 06:41:40 -0700 (PDT)
Received: by mail-ig0-f173.google.com with SMTP id h18so17344302igc.12 for ; Wed, 15 Oct 2014 06:41:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/1myMsigjb0AqG0Z+AxjBJ/izOjog9hkM/+XbldBj7I=; b=Vj0q/lmNCWP/iOoUyEVPeWHlWychCAg/PYzBkP358EfKKl9wdpCbUbuZqAQO03wbnO +aB0Rr05yJlkgts3aDNl7Bluhje1ay+oWI04E2XCmmAP3ZJhEJHwaJwH5+VpTR85ZXvz zKjjHwPigBArIvbraugF02ZzLx0Rb1LDkXoSQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=/1myMsigjb0AqG0Z+AxjBJ/izOjog9hkM/+XbldBj7I=; b=avrTTPyyKg86kx6Ka5bYkvO/WxR+MDZSBBJ6pv/mfwzmkwfnnjm7Cv4Wl9sDPDLPpH QvgXrW6AsFxsmwHDpuqyDECre8cdx+4oP0YbzxFPLvGZf3Nt+Qs4uyQuSnQOLGE7mmvN ieVl/N5+AoESQuiWsNg1c2YGizmok9CZx9aSSWBX++En17uAHOw7TrN5Pul5zhwLUxQ9 a7XQmeVROlgmql92KRqIIGD6BZJoXQErcpc+hFBsh2ocklsIzqyzCTfZK/QSsBqMnvAZ n+hav8KckyyPAmzrPMFT/66WrJUo3wYWYavcvi8xfJkgZMFrhnRXYE+cM2oIHh9bpT9N cQLA==
X-Gm-Message-State: ALoCoQkRKxYPk3C7vNPEEO77CdTMCWrYxleITLFjX3RLyVrMjB267T8w+8zpi2zyNx5JqhNjNZ+O
X-Received: by 10.43.94.7 with SMTP id bw7mr11411269icc.30.1413380500134; Wed, 15 Oct 2014 06:41:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.15 with HTTP; Wed, 15 Oct 2014 06:41:19 -0700 (PDT)
In-Reply-To: <20141015140158.41a1faf8@pc.my-domain>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <20141015140158.41a1faf8@pc.my-domain>
From: Tom Ritter 
Date: Wed, 15 Oct 2014 08:41:19 -0500
Message-ID: 
To: =?ISO-8859-1?Q?Hanno_B=F6ck?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JQVozchnPuWyDv8UlEmqXY3WYoQ
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 13:41:42 -0000

On 15 October 2014 07:01, Hanno B=F6ck  wrote:
> * Support people who deploy correct implementations, punish people who
>   support broken stuff

I think the last bullet may also be stated as "punish users trying to
connect to broken stuff".  As Bodo mentioned, browsers would like to
remove protocol downgrades, partly because they represent a security
vulnerability.  But the priority is to users and not breaking the
Internet in these situations (hard-fail OCSP is another example, CA
blacklisting a third).  The constraint we have (putting up with the
downgrade dance) means we have two options: deploy this SCSV and
protect your users, or do not deploy it and don't.

It's fair to reject the constraint and push for a more perfect
protocol, and in some situations I agree with you.  In this situation,
I accept the dirtiness in the interest of providing a way to protect
users.  Perhaps this should be "Informational" or "Experimental" to
try and isolate it from TLS? But regardless, I would like to see it
documented, implemented, and deployed.

-tom


From nobody Wed Oct 15 07:57:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBD31A70E2 for ; Wed, 15 Oct 2014 07:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.48
X-Spam-Level: **
X-Spam-Status: No, score=2.48 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXRzvg3p0QBQ for ; Wed, 15 Oct 2014 07:57:21 -0700 (PDT)
Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.22.86]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7EE71A1ADA for ; Wed, 15 Oct 2014 07:57:21 -0700 (PDT)
Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id AD56150DD32DE; Wed, 15 Oct 2014 09:57:20 -0500 (CDT)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 9AD3950DD3237 for ; Wed, 15 Oct 2014 09:57:20 -0500 (CDT)
Received: from [173.73.121.234] (port=54187 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XeQ0t-0006Ol-WE for tls@ietf.org; Wed, 15 Oct 2014 09:57:20 -0500
From: Sean Turner 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <20C76880-66F3-4DA4-8A23-31D006B915B3@ieca.com>
Date: Wed, 15 Oct 2014 10:57:18 -0400
To: "TLS@ietf.org (tls@ietf.org)" 
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 173.73.121.234
X-Exim-ID: 1XeQ0t-0006Ol-WE
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([192.168.1.7]) [173.73.121.234]:54187
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 6
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7m4WA5zAL8XtNutDC7x5IreCGjQ
Subject: [TLS] final Paris interim attendance check
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 14:57:22 -0000

Alfredo has update the wiki to include who I=92ve noted is coming to the =
Paris interim.  If you don=92t see your name on the list please let me =
know ASAP.

=
https://wiki.inria.fr/prosecco/IETF_TLS_Interim_October_2014#List_of_local=
_attendees

spt=


From nobody Wed Oct 15 08:14:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6CD1A86F4 for ; Wed, 15 Oct 2014 08:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvYmUn2Nc4Kj for ; Wed, 15 Oct 2014 08:14:29 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BCA1A8785 for ; Wed, 15 Oct 2014 08:14:28 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FFER94025959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 15 Oct 2014 11:14:27 -0400
Received: from oldenburg.str.redhat.com (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FFEOSu003948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 15 Oct 2014 11:14:26 -0400
Message-ID: <543E8F4F.5070902@redhat.com>
Date: Wed, 15 Oct 2014 17:14:23 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9vC7uTCmQlUBT57w83HXakjESvQ
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 15:14:37 -0000

On 10/15/2014 11:22 AM, Bodo Moeller wrote:
> Note that if your server does not support formally obsolete protocol
> versions, TLS_FALLBACK_SCSV support is a no-op.

No, only if you support exactly a single TLS version.  Then the presence 
of TLS_FALLBACK_SCSV support in the server code is indeed unobservable.

(As long as the presence of this feature is observable, server operators 
will be bullied into implementing it, with broken network-based testers 
etc.  It's not really optional.)

> Otherwise, you're making real-world tradeoffs, and I think
> TLS_FALLBACK_SCSV is a reasonable one to make (with minimal server-side
> logic to achieve the objective), not "punishment".

It's still punishes those who are responsible netizens and can update 
their servers—simply because they have to apply an update.  Their client 
base doesn't even directly benefit from that, it's just to enable their 
clients to preserve their own brokeness, so that they can continue to 
connect to broken servers that may or may not be out there.

Meanwhile, those who operate TLS-version-intolerant servers have to 
do—nothing.  That's what I find unfair and unsustainable.

-- 
Florian Weimer / Red Hat Product Security


From nobody Wed Oct 15 08:20:21 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FA01A86F0 for ; Wed, 15 Oct 2014 08:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6pEM1y8gXSy for ; Wed, 15 Oct 2014 08:20:14 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78E931A1B1C for ; Wed, 15 Oct 2014 08:20:14 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FFKCcx027931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 15 Oct 2014 11:20:13 -0400
Received: from oldenburg.str.redhat.com (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FFK9C8008667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 15 Oct 2014 11:20:12 -0400
Message-ID: <543E90A9.5030003@redhat.com>
Date: Wed, 15 Oct 2014 17:20:09 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <20141015140158.41a1faf8@pc.my-domain> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com> <20141015143611.1c7b079b@pc> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE85E@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE85E@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9MHKuPcLjNOg4B0e6pl_EgSfSyQ
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 15:20:19 -0000

On 10/15/2014 02:43 PM, Salz, Rich wrote:
>> So the number I want to see is: How many servers are there that are not
>> capable of correctly negotiating the SSL/TLS versions they support?
>
> That's not the question that SCSV is trying to address.
>
> The question is:  how many clients end up using SSLv3 when the could use something better?

But the new SCSV will make things worse for accidental protocol 
downgrades (which happen quite frequently with Firefox, it seems).  What 
is now a protocol downgrade will turn into a hard connection failure.

Will the new SCSV enable additional clients to switch on more recent TLS 
versions by default?  I don't think so—you'd still need to code the 
fallback logic separately and outside of the TLS implementation (e.g., 
to support things like STARTTLS, which the TLS implementation typically 
doesn't know about).

-- 
Florian Weimer / Red Hat Product Security


From nobody Wed Oct 15 08:24:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CD81A876C for ; Wed, 15 Oct 2014 08:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-OlP-olE0wg for ; Wed, 15 Oct 2014 08:24:12 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD3F1A8766 for ; Wed, 15 Oct 2014 08:24:12 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FFOBEM021623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 15 Oct 2014 11:24:11 -0400
Received: from oldenburg.str.redhat.com (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FFO8Fc025681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 15 Oct 2014 11:24:10 -0400
Message-ID: <543E9197.9080906@redhat.com>
Date: Wed, 15 Oct 2014 17:24:07 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>    
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/huGVO3coHFwUIfp5UWSd7Xl5vb4
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 15:24:13 -0000

On 09/26/2014 08:37 PM, Adam Langley wrote:
> If an administrator is worried that version x is too weak, then all
> versions <= x need to be disabled too I believe? I can't think of a
> security concern that is not monotonic with respect to TLS versions.

An administrator may want to support local security services and run 
specific protocol versions and ciphers for which the security services 
have interception capabilities, to cut down the legal paperwork. :-)

-- 
Florian Weimer / Red Hat Product Security


From nobody Wed Oct 15 08:35:26 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0561A8825 for ; Wed, 15 Oct 2014 08:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eySk9R-CZOMt for ; Wed, 15 Oct 2014 08:35:22 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155191A87F1 for ; Wed, 15 Oct 2014 08:35:22 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FFZL2b029559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 15 Oct 2014 11:35:21 -0400
Received: from oldenburg.str.redhat.com (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FFZIpQ019175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 15 Oct 2014 11:35:20 -0400
Message-ID: <543E9435.8000905@redhat.com>
Date: Wed, 15 Oct 2014 17:35:17 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org>
In-Reply-To: <5438CFEA.7000401@brainhub.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JyVm9BAnKZDCYh5AayILASUid0w
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 15:35:23 -0000

On 10/11/2014 08:36 AM, Andrey Jivsov wrote:
> On 09/25/2014 09:00 PM, Joseph Salowey (jsalowey) wrote:
>> This is an announcement for the working group last call for
>> draft-ietf-tls-downgrade-scsv-00.  Please review the document and send
>> your comments to the list by Friday, October 17, 2014.
>>
>> Thanks,
>> J&S
>
>
>> 3. Server behavior
>
> Suppose a server and a client support TLS1.2, client starts with TLS1.2
> but network failure makes the client reconnect with TLS1.1. Or perhaps
> there is an occasional bug in TLS1.2 path on the client or the server,
> leading to the same TLS1.1 reconnect.
>
> In this case the server is prescribed to fail with
> inappropriate_fallback for TLS1.1 + SCSV.

This scenario is described here:



SCSV implementation would make things worse for Firefox users because it 
results in a reliable connection failure instead of a downgrade from TLS 
1.1 to TLS 1.2.

-- 
Florian Weimer / Red Hat Product Security


From nobody Wed Oct 15 08:45:29 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755F31A8851 for ; Wed, 15 Oct 2014 08:45:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIJmInzygnYR for ; Wed, 15 Oct 2014 08:45:24 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760BD1A884C for ; Wed, 15 Oct 2014 08:45:24 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FFfc67000762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 15 Oct 2014 11:41:38 -0400
Received: from oldenburg.str.redhat.com (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FFfZHd004400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 15 Oct 2014 11:41:37 -0400
Message-ID: <543E95AE.1030300@redhat.com>
Date: Wed, 15 Oct 2014 17:41:34 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
In-Reply-To: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PPayMQ4JxQ9Zxyv0WyTn5jJZjNk
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 15:45:26 -0000

On 09/26/2014 06:00 AM, Joseph Salowey (jsalowey) wrote:
> This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your comments to the list by Friday, October 17, 2014.

One more issue: The draft is silent on how to respond to an 
inappropriate_fallback alert.  Considering that the draft was prompted 
by inappropriate responses to handshake alerts (and network failures 
during the handshake), this omission is curious.

Will we add

         TLS_FALLBACK_NO_THIS_TIME_I_REALL_MEAN_IT_SCSV   {0x56, 0x01}

in a few months or years?  Where does it end?

-- 
Florian Weimer / Red Hat Product Security


From nobody Wed Oct 15 09:08:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136331A88B9 for ; Wed, 15 Oct 2014 09:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qinPQWVTnvWV for ; Wed, 15 Oct 2014 09:08:20 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6F21A8893 for ; Wed, 15 Oct 2014 09:08:20 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BE7FA475FF; Wed, 15 Oct 2014 16:08:19 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B272947567; Wed, 15 Oct 2014 16:08:19 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id AEDE480044; Wed, 15 Oct 2014 16:08:19 +0000 (GMT)
Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 15 Oct 2014 12:08:19 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 15 Oct 2014 12:08:18 -0400
From: "Salz, Rich" 
To: Florian Weimer , "tls@ietf.org" 
Date: Wed, 15 Oct 2014 12:08:15 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/ojaggEQT3N+NSSmiVB2Ux5b7dVwABDQQg
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com>
In-Reply-To: <543E9435.8000905@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qtHXWxZW5872nVvVOVh9tXa3neY
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:08:23 -0000

> SCSV implementation would make things worse for Firefox users because it
> results in a reliable connection failure instead of a downgrade from TLS
> 1.1 to TLS 1.2.

Yes, exactly.  If a browser is going to fallback, it could ask the user "I'=
m going to retry, and you'll lose PFS; if the server is ever cracked by the=
 NSA all your data will be readable.  Proceed?" If the usre clicks yes, the=
n the browser tries again with the fallback SCSV.   (I would hope that the =
user-agent would provide more understable message, but I'm not optimistic.)

The point kis that a transient network error has highly visible security im=
plications.

HTTP doesn't auto-retry, either.

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Wed Oct 15 09:12:54 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C071A891F for ; Wed, 15 Oct 2014 09:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkj0zBVeUpJX for ; Wed, 15 Oct 2014 09:12:44 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4661A892A for ; Wed, 15 Oct 2014 09:11:18 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FGBFkk016592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 15 Oct 2014 12:11:16 -0400
Received: from oldenburg.str.redhat.com (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FGBBUX019932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2014 12:11:14 -0400
Message-ID: <543E9C9F.5050104@redhat.com>
Date: Wed, 15 Oct 2014 18:11:11 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: "Salz, Rich" , "tls@ietf.org" 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-kzU3NqlCIaWQ9FwgYh9F98oDpk
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:12:48 -0000

On 10/15/2014 06:08 PM, Salz, Rich wrote:
>> SCSV implementation would make things worse for Firefox users because it
>> results in a reliable connection failure instead of a downgrade from TLS
>> 1.1 to TLS 1.2.
>
> Yes, exactly.  If a browser is going to fallback, it could ask the user "I'm going to retry, and you'll lose PFS; if the server is ever cracked by the NSA all your data will be readable.  Proceed?" If the usre clicks yes, then the browser tries again with the fallback SCSV.   (I would hope that the user-agent would provide more understable message, but I'm not optimistic.)
>
> The point kis that a transient network error has highly visible security implications.
>
> HTTP doesn't auto-retry, either.

I was trying to point out that HTTPS in Firefox actually did retry, in 
many cases successfully, and now it doesn't (attempts to retry will fail 
consistently).  That smells like a regression in the making.

-- 
Florian Weimer / Red Hat Product Security


From nobody Wed Oct 15 09:13:21 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802201A88C7 for ; Wed, 15 Oct 2014 09:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQJhbni21Nnk for ; Wed, 15 Oct 2014 09:13:16 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 843FC1A8903 for ; Wed, 15 Oct 2014 09:12:05 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DE7412858E; Wed, 15 Oct 2014 16:12:04 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id CCAD72858B; Wed, 15 Oct 2014 16:12:04 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id C621C80047; Wed, 15 Oct 2014 16:12:04 +0000 (GMT)
Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 15 Oct 2014 12:12:04 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 15 Oct 2014 12:12:03 -0400
From: "Salz, Rich" 
To: "Salz, Rich" , Florian Weimer , "tls@ietf.org" 
Date: Wed, 15 Oct 2014 12:12:01 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/ojaggEQT3N+NSSmiVB2Ux5b7dVwABDQQgAAAyk+A=
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D3@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/D3C3LuFLhVI4bmgDFKLzRpz4_Q0
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:13:17 -0000

> Yes, exactly.  If a browser is going to fallback, it could ask the user "=
I'm going
> to retry, and you'll lose PFS; if the server is ever cracked by the NSA a=
ll your
> data will be readable.  Proceed?" If the usre clicks yes, then the browse=
r tries
> again with the fallback SCSV.   (I would hope that the user-agent would
> provide more understable message, but I'm not optimistic.)

Arrgh.  Tries again WITHOUT the fallback SCSV.
=20
> The point kis that a transient network error has highly visible security
> implications.
>=20
> HTTP doesn't auto-retry, either.

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz



From nobody Wed Oct 15 09:13:59 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10791A88FD for ; Wed, 15 Oct 2014 09:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJP6S7F3OIGy for ; Wed, 15 Oct 2014 09:13:50 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 625721A8900 for ; Wed, 15 Oct 2014 09:13:31 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 05D592858E; Wed, 15 Oct 2014 16:13:31 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id E6F6F2858B; Wed, 15 Oct 2014 16:13:30 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id E40E680048; Wed, 15 Oct 2014 16:13:30 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 15 Oct 2014 12:13:30 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 15 Oct 2014 12:13:30 -0400
From: "Salz, Rich" 
To: Florian Weimer , "tls@ietf.org" 
Date: Wed, 15 Oct 2014 12:13:28 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/okqgheTxBhx3tQXOseFX3vqSglQAAB3kA
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com>
In-Reply-To: <543E9C9F.5050104@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vhBJQeOM20F4njfp4h52Zy88pS4
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:13:55 -0000

It retried because there was no way to indicate "let me try again with olde=
r version"  Now there is a way to indicate that this is happening.  Servers=
 who support better protocols will reject the connection because the browse=
r might be unwittingly giving up valuable security properties.  Servers who=
 don't support better protocols will complete the handshake.

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz



From nobody Wed Oct 15 09:19:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38961A88B1 for ; Wed, 15 Oct 2014 09:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP5otY1BjhSO for ; Wed, 15 Oct 2014 09:19:39 -0700 (PDT)
Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF791A88B0 for ; Wed, 15 Oct 2014 09:19:39 -0700 (PDT)
Received: by mail-yh0-f41.google.com with SMTP id i57so749092yha.14 for ; Wed, 15 Oct 2014 09:19:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N6GOY3eluCyT+bww3wqkBiL477ZziGLDqP4Euea4GJk=; b=NMNLoQrKCBYy5McP0YtxHgOHBRzGE7xlXNpUqZFWJt9daZir99yZgl+IgI2AsE6Xg+ /MHr8gJ4OpYR+LzfEg7TW393U37xwxhWLkTypel8lfP4syR1dgJImGp4Yu0QqqS86v3N gP6qUsHnOr3acRtRyeV1cfKPp24RyPX2l4b/SeWW5pDW5YKGrqkVReRL9G6q4CYi8T7V 6EsYGAIDFgU1vzLYN81SJyYDjyIxWz2xPcTOlGDJEpX+5b4efyVx/GsMaBhn23YUQRuR 9bwpfO5Gce8w4SRC+MMDKRGdPu+kBMR/HnFaNGN/GKxZHljxO5eGUNLpqFw4Ak7rR2BH QrAw==
MIME-Version: 1.0
X-Received: by 10.236.17.197 with SMTP id j45mr18448855yhj.49.1413389978431; Wed, 15 Oct 2014 09:19:38 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Wed, 15 Oct 2014 09:19:38 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Wed, 15 Oct 2014 09:19:38 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 15 Oct 2014 09:19:38 -0700
Message-ID: 
From: Watson Ladd 
To: Sean Turner 
Content-Type: multipart/alternative; boundary=047d7b603c5898e4910505787f23
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xPy5cSd7mLtLruN3d3Of5kz4Lco
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] draft agenda TLS WG interim 21-22 October
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:19:43 -0000

--047d7b603c5898e4910505787f23
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 9, 2014 at 4:27 AM, Sean Turner  wrote:
> All,
>
> Here=E2=80=99s a draft agenda, which can also be found @ the interim meet=
ing site:
> http://www.ietf.org/meeting/interim/proceedings.html
> Please let me know if you have anything to add:
>
> Day 1: October 21 (mostly TLS maintenance)
>
> 0900 - 0930 Get Settled, Administrivia, Agenda (30 min)
> 0930 - 1030 Session Hash for 1.2
> 1030 - 1100 Break
> 1100 - 1145 Downgrade SCSV
> 1145 - 1300 Lunch
> 1300 - 1345 Deprecating RC4: 2119 levels (Andrei on Phone)
> 1345 - 1430 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters
> for TLS (what's left to decide?)
> 1500 - 1530 Break
> 1530 - 1700 TLS 1.3 Named Group negotiation (follow up from YYZ)
>
> [break]
>
> 1800 - late Dinner
>
>
> Day 2: October 22 (mostly TLS 1.3)
> 0900 - 0915 Get Settled, Administrivia, Agenda (15 min)
> 0915 - 1000 Session-Hash for 1.3
> 1000 - 1030 Resumption (do we still need it)
> 1030 - 1100 Break
> 1100 - 1200 Key Refresh/Refactoring Client Auth (I)
> 1200 - 1315 Lunch
> 1315 - 1415 Key Refresh/Refactoring Client Auth (II)
> 1415 - 1500 0-RTT (I)
> 1500 - 1530 Break
> 1530 - 1630 0-RTT (II)
> 1630 - 1700 Intentionally left open.

Is there a concrete proposal for replacing resumption that is being
discussed, or is this brainstorming? Also, for Key Refresh/Refactoring
Client auth, what are the options? (Same for 0-RTT) Do I need to break
things or do a literature search or what to help out?
>
> J&S
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

--047d7b603c5898e4910505787f23
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 9, 2014 at 4:27 AM, Sean Turner <TurnerS@ieca.com> wrote:

> All,

>

> Here=E2=80=99s a draft agenda, which can also be found @ the interim m=
eeting site:

> http:=
//www.ietf.org/meeting/interim/proceedings.html

> Please let me know if you have anything to add:

>

> Day 1: October 21 (mostly TLS maintenance)

>

> 0900 - 0930 Get Settled, Administrivia, Agenda (30 min)

> 0930 - 1030 Session Hash for 1.2

> 1030 - 1100 Break

> 1100 - 1145 Downgrade SCSV

> 1145 - 1300 Lunch

> 1300 - 1345 Deprecating RC4: 2119 levels (Andrei on Phone)

> 1345 - 1430 Negotiated Finite Field Diffie-Hellman Ephemeral Parameter=
s

> for TLS (what's left to decide?)

> 1500 - 1530 Break

> 1530 - 1700 TLS 1.3 Named Group negotiation (follow up from YYZ)

>

> [break]

>

> 1800 - late Dinner

>

>

> Day 2: October 22 (mostly TLS 1.3)

> 0900 - 0915 Get Settled, Administrivia, Agenda (15 min)

> 0915 - 1000 Session-Hash for 1.3

> 1000 - 1030 Resumption (do we still need it)

> 1030 - 1100 Break

> 1100 - 1200 Key Refresh/Refactoring Client Auth (I)

> 1200 - 1315 Lunch

> 1315 - 1415 Key Refresh/Refactoring Client Auth (II)

> 1415 - 1500 0-RTT (I)

> 1500 - 1530 Break

> 1530 - 1630 0-RTT (II)

> 1630 - 1700 Intentionally left open.


Is there a concrete proposal for replacing resumption that i=
s being discussed, or is this brainstorming? Also, for Key Refresh/Refactor=
ing Client auth, what are the options? (Same for 0-RTT) Do I need to break =
things or do a literature search or what to help out?

>

> J&S

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf=
.org/mailman/listinfo/tls



--

"Those who would give up Essential Liberty to purchase a little Tempor=
ary Safety deserve neither Liberty nor Safety."

-- Benjamin Franklin


--047d7b603c5898e4910505787f23--


From nobody Wed Oct 15 09:25:40 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E921A047A for ; Wed, 15 Oct 2014 09:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cHc4xrsz_qD for ; Wed, 15 Oct 2014 09:25:37 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F8F1A88CD for ; Wed, 15 Oct 2014 09:25:37 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FGPYAG018119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 15 Oct 2014 12:25:34 -0400
Received: from oldenburg.str.redhat.com (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FGPUJG028473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2014 12:25:33 -0400
Message-ID: <543E9FFA.5030102@redhat.com>
Date: Wed, 15 Oct 2014 18:25:30 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: "Salz, Rich" , "tls@ietf.org" 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/p_XX_K8Zl5pPT9q7-8FdPMwIiVE
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:25:39 -0000

On 10/15/2014 06:13 PM, Salz, Rich wrote:
> It retried because there was no way to indicate "let me try again with older version"  Now there is a way to indicate that this is happening.  Servers who support better protocols will reject the connection because the browser might be unwittingly giving up valuable security properties.  Servers who don't support better protocols will complete the handshake.

Sorry, but please review the Mozilla bug and re-read what I wrote.  I 
have a feeling that we both are talking about different things.

I'm concerned that a straightforward implementation of this new SCSV in 
Firefox will introduce user-visible connection failures when the 
downgrade is caused by a (likely spurious) networking event.  It's true 
that this network failure could be introduced deliberately by an on-path 
attacker (but even the SCSV design assumes that's rare*).  It's also 
true that an attacker can disguise most attacks as networking anomalies. 
  But it's unfortunate that this SCSV has such a broad area of ambiguity 
which does not help with browser UI design at all.

I understand that the ship has sailed on this one, and that we cannot 
change the protocol anymore.  So publishing the RFC seems unavoidable at 
this point, if only to ensure the codepoint reservations stick.


*) Deploying an SCSV-enabled browser to users on an intercepting network 
will largely knock these users off the net (assuming that SCSV support 
is widely deployed in public-facing TLS termination), so such attacks 
are hopefully very isolated, or else it's not possible to deploy this 
feature in browsers.

-- 
Florian Weimer / Red Hat Product Security


From nobody Wed Oct 15 09:27:13 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308311A88F9 for ; Wed, 15 Oct 2014 09:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h6Of4zMUMry for ; Wed, 15 Oct 2014 09:27:11 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF921A8791 for ; Wed, 15 Oct 2014 09:27:11 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 78773165930 for ; Wed, 15 Oct 2014 16:27:10 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 6D7CA165929 for ; Wed, 15 Oct 2014 16:27:10 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 54ADC1E041 for ; Wed, 15 Oct 2014 16:27:10 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 15 Oct 2014 12:26:55 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 15 Oct 2014 12:26:55 -0400
From: "Salz, Rich" 
To: "TLS@ietf.org (tls@ietf.org)" 
Date: Wed, 15 Oct 2014 12:26:52 -0400
Thread-Topic: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein)
Thread-Index: Ac/okJmQ5/RYF5DuRWS268uANGNG0wAA+zSg
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9F4@USMBX1.msg.corp.akamai.com>
References:  <543E5B35.5000604@iang.org>    <543E992C.7000802@cs.tcd.ie>
In-Reply-To: <543E992C.7000802@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sClwCuiC_32XzJ3HGGt0oe_IhNk
Subject: [TLS] FW: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:27:12 -0000

>From Mr. Farrell in the SAAG mailing list:

>If they can now get rid of SSLv3 within say a couple of months, (and I hop=
e they can), then we should maybe be asking ourselves if we (the IETF) can =
help 'em somehow not let such stuff linger for so long in future. Not sure =
how, but say if we'd published an "SSLv3 considered possibly harmful" RFC a=
bout 8 years after RFC 2246 was published, do we think that might have help=
ed, or might an equivalent help in future? Looking about randomly, I see TL=
S1.1 is 8 years old now:-)

> And just to clarify, my question isn't really about TLS, but about whethe=
r there's an IETF thing to be done here that might help. (And the answer fo=
r now is I'm not sure.)

I'd like suggest we spend some time chatting about this.  Maybe it's just o=
ver fine bottled water at dinner, or maybe it's an official agenda item.  W=
hile he's right to be concerned about the larger problem, I think that as t=
he "canary in the coal mine" and the most bruised and battered protocol, we=
 might be a very group to help kickstart this.


From nobody Wed Oct 15 09:29:28 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A111A8948 for ; Wed, 15 Oct 2014 09:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQL9z3PWznV3 for ; Wed, 15 Oct 2014 09:29:26 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8BC1A8940 for ; Wed, 15 Oct 2014 09:29:26 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CCEC04877B; Wed, 15 Oct 2014 16:29:25 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id C1A5C4876E; Wed, 15 Oct 2014 16:29:25 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id A9B051E041; Wed, 15 Oct 2014 16:29:25 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 15 Oct 2014 12:29:24 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 15 Oct 2014 12:29:24 -0400
From: "Salz, Rich" 
To: Florian Weimer , "tls@ietf.org" 
Date: Wed, 15 Oct 2014 12:29:22 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/olKfleAs/C8c2Th2DAYbj7UMaGwAAD63A
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9FD@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>
In-Reply-To: <543E9FFA.5030102@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KI7m9gsN_R-RwVGdlLXZHhI3vOU
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:29:27 -0000

A spurious network event that gave up security properties SHOULD NOT quietl=
y give those up on behalf of the user.

I betcha browsers soon retry with their best version, before decided when/h=
ow to fallback.

Network hiccups happen all the time. For plaintext protocols they are benig=
n. For security protocols that would silently give up features they are not=
.

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Wed Oct 15 09:52:26 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4991A1A1B96 for ; Wed, 15 Oct 2014 09:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSfB4viOMnQI for ; Wed, 15 Oct 2014 09:52:21 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51CE61A1B6D for ; Wed, 15 Oct 2014 09:52:21 -0700 (PDT)
Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0Mg2TZ-1Xqu7r2w69-00NPKF; Wed, 15 Oct 2014 18:52:19 +0200
Received: by mail-yh0-f44.google.com with SMTP id i57so782332yha.3 for ; Wed, 15 Oct 2014 09:52:17 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.110.35 with SMTP id t23mr15720592yhg.126.1413391937437;  Wed, 15 Oct 2014 09:52:17 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 09:52:17 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 09:52:17 -0700 (PDT)
In-Reply-To: <543E8F4F.5070902@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <543E8F4F.5070902@redhat.com>
Date: Wed, 15 Oct 2014 18:52:17 +0200
Message-ID: 
From: Bodo Moeller 
To: Florian Weimer 
Content-Type: multipart/alternative; boundary=001a1133358a5c0511050578f45f
X-Provags-ID: V02:K0:uG79vEailCprp0pY4D7q/mmleUg03DOOJ0kD9hy1xLF cJptbt15cG/W8ypDj0jkluRZJ2Mu3xP/oLpxpMwZQBM4xqKUcy bSvEjomf8J8vEIGTz/Z+NuNK9bb+XyTYA6AmzdXRkntilc1HaS 8vjWn0fXTq3YhkxJL93iZVQvM2QvazhwzKsp3G1CtjgiWaOjY1 dIXRvLPkPkSsOt/DVxaeLDZh7VTQLMDDslDMJ90GgnfvMiEh3I 6HA0vwXRQ6Q5y7i49PQVBrKxoHWJsPonwygDr6ZFiacZxPop2I x/pnS/YpW89ab40aH1DTHyjnsCxJrLCvLwAwF9WSgO1bJIz+Gz VAHl4tpqat6bis9y5m/YoSJJujRiz4itLr891bA7Lbd5KIX4pN YNEwaRq0YFegmCJpcUsZ4x3YVWyI0sO5RUL1JT1tqNYZMqe0CY XspiM
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TvKEnbDixr0jLGeJ82LxJQBEvV8
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:52:24 -0000

--001a1133358a5c0511050578f45f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

"Florian Weimer" :
> On 10/15/2014 11:22 AM, Bodo Moeller wrote:

>> Note that if your server does not support formally obsolete protocol
>> versions, TLS_FALLBACK_SCSV support is a no-op.

> No, only if you support exactly a single TLS version.  Then the presence
of TLS_FALLBACK_SCSV support in the server code is indeed unobservable.

I was teasing. So far at least, every new protocol version has formally
obsoleted the previous version, so we've only ever had a single
non-deprecated TLS version.

Real life, necessarily, is a different matter; that's the real point I
wanted to make.

>> Otherwise, you're making real-world tradeoffs, and I think
>> TLS_FALLBACK_SCSV is a reasonable one to make (with minimal server-side
>> logic to achieve the objective), not "punishment".

> It's still punishes those who are responsible netizens and can update
their servers=E2=80=94simply because they have to apply an update.  Their c=
lient
base doesn't even directly benefit from that, it's just to enable their
clients to preserve their own brokeness, so that they can continue to
connect to broken servers that may or may not be out there.

This is right, but I don't consider it "punishment". (And in practice,
you'll have to apply occasional  implementation bugfix updates anyway, and
the protocol change may not pose any extra effort.)

> Meanwhile, those who operate TLS-version-intolerant servers have to
do=E2=80=94nothing.

If you insist on "punishment", the very least happening to them is an
increased rate of incoming connections, and increased latency for their
users. There are no technical means to force them to address that if they
don't care about their users, but in that case, what could you do?

Bodo

Bodo

--001a1133358a5c0511050578f45f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


"Florian Weimer" <fweimer@redhat.com>:

> On 10/15/2014 11:22 AM, Bodo Moeller wrote:


>> Note that if your server does not support formally =
obsolete protocol

>> versions, TLS_FALLBACK_SCSV support is a no-op.


> No, only if you support exactly a single TLS version.=
=C2=A0 Then the presence of TLS_FALLBACK_SCSV support in the server code is=
 indeed unobservable.


I was teasing. So far at least, every new protocol version h=
as formally obsoleted the previous version, so we've only ever had a si=
ngle non-deprecated TLS version.


Real life, necessarily, is a different matter; that's th=
e real point I wanted to make.


>> Otherwise, you're making real-world tradeoffs, =
and I think

>> TLS_FALLBACK_SCSV is a reasonable one to make (with minimal server=
-side

>> logic to achieve the objective), not "punishment".


> It's still punishes those who are responsible netiz=
ens and can update their servers=E2=80=94simply because they have to apply =
an update.=C2=A0 Their client base doesn't even directly benefit from t=
hat, it's just to enable their clients to preserve their own brokeness,=
 so that they can continue to connect to broken servers that may or may not=
 be out there.


This is right, but I don't consider it "punishment&=
quot;. (And in practice, you'll have to apply occasional=C2=A0 implemen=
tation bugfix updates anyway, and the protocol change may not pose any extr=
a effort.)


> Meanwhile, those who operate TLS-version-intolerant ser=
vers have to do=E2=80=94nothing.


If you insist on "punishment", the very least happ=
ening to them is an increased rate of incoming connections, and increased l=
atency for their users. There are no technical means to force them to addre=
ss that if they don't care about their users, but in that case, what co=
uld you do?


Bodo


Bodo


--001a1133358a5c0511050578f45f--


From nobody Wed Oct 15 09:55:46 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BAA1A8A0E for ; Wed, 15 Oct 2014 09:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFAXG7fbLvBm for ; Wed, 15 Oct 2014 09:55:41 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF9A1A8A11 for ; Wed, 15 Oct 2014 09:55:40 -0700 (PDT)
Received: from mail-yh0-f41.google.com (mail-yh0-f41.google.com [209.85.213.41]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0MFRbQ-1XQ7zy374u-00ELTF; Wed, 15 Oct 2014 18:55:39 +0200
Received: by mail-yh0-f41.google.com with SMTP id i57so782364yha.14 for ; Wed, 15 Oct 2014 09:55:36 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.110.35 with SMTP id t23mr15748074yhg.126.1413392136740;  Wed, 15 Oct 2014 09:55:36 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 09:55:36 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 09:55:36 -0700 (PDT)
In-Reply-To: <543E9435.8000905@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com>
Date: Wed, 15 Oct 2014 18:55:36 +0200
Message-ID: 
From: Bodo Moeller 
To: Florian Weimer 
Content-Type: multipart/alternative; boundary=001a1133358a3d238c05057900ef
X-Provags-ID: V02:K0:NJSIWqX3A9dZPmE+7uIOeF9aTVsHPF4UsHg1E68Cgft ICJQnC+BKOrXuqVnUpbg8PqEkm9zfAd7+TbKe2wJCepGoQWUOJ Hs/4Ba2tsCKSELTno62CWcNiOVf6NivDn0NA23Vjyg4qXehQW2 63XJhdFg1WE54CmPmWKmAqsMYUOSWTHezufZqpramdPDiBPrbd daGWoAxFfQFvOIqrg6ugqQwKXesvCEHHHfxST5Zc1/znehFD6w JL0etZsO2rhOSSLn01YjXhCaVKO+0TxiVL5F5JMoJyXlz2Jv8l J+ljdux2e6L2gQ71/ZYimddBZeCFZ41PdqW/3gQJmyfrdbGvDX D5EZssPHjrraVeElReqQs9qMHgHZ9v0ni3Htik41bW1teUmamG 0G2ClLqjrVnhXLjIsqTmtcj0lOA91wY2MYlMxUucUCg/O9l5wi QnReo
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OPAeOQvDbzqUaCr6uDOPgdn19f0
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:55:42 -0000

--001a1133358a3d238c05057900ef
Content-Type: text/plain; charset=UTF-8

"Florian Weimer" :

> This scenario is described here:
>
> 
>
> SCSV implementation would make things worse for Firefox users because it
results in a reliable connection failure instead of a downgrade from TLS
1.1 to TLS 1.2.

That is (well, *was*) a clear bug in that particular implementation.

Bodo

--001a1133358a3d238c05057900ef
Content-Type: text/html; charset=UTF-8


"Florian Weimer" <fweimer@redhat.com>:


> This scenario is described here:

>

> <https://bugzilla.mozilla.org/show_bug.cgi?id=450280>

>

> SCSV implementation would make things worse for Firefox users because it results in a reliable connection failure instead of a downgrade from TLS 1.1 to TLS 1.2.


That is (well, *was*) a clear bug in that particular implementation.


Bodo


--001a1133358a3d238c05057900ef--


From nobody Wed Oct 15 11:09:49 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5E31A903B for ; Wed, 15 Oct 2014 11:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.961
X-Spam-Level: 
X-Spam-Status: No, score=0.961 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDOs4tQzF31t for ; Wed, 15 Oct 2014 11:09:47 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009A51A9039 for ; Wed, 15 Oct 2014 11:09:46 -0700 (PDT)
Received: from mail-yh0-f46.google.com (mail-yh0-f46.google.com [209.85.213.46]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0M7Jw6-1YP8QQ33zS-00x1GL; Wed, 15 Oct 2014 20:09:45 +0200
Received: by mail-yh0-f46.google.com with SMTP id f73so842375yha.19 for ; Wed, 15 Oct 2014 11:09:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.203.114 with SMTP id e78mr19401522yho.47.1413396582683;  Wed, 15 Oct 2014 11:09:42 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 11:09:41 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 11:09:41 -0700 (PDT)
In-Reply-To: <543E95AE.1030300@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E95AE.1030300@redhat.com>
Date: Wed, 15 Oct 2014 20:09:41 +0200
Message-ID: 
From: Bodo Moeller 
To: Florian Weimer 
Content-Type: multipart/alternative; boundary=089e0158c7c43cdc7305057a0970
X-Provags-ID: V02:K0:/+jP8u7091lXqNgdygie2A07upyNpINvqUW9NEcw7Qu DjRvRnuSWd3FHO16C/JRPmr+pApbetDhad0m+e2E+P99YPWn08 YeoZe2mCn5YZW6v0vrGcFqqJmjQ9kVx82GkAbosDRM9/EGs9rb dJXWdKr0xP9ZIG9zFph6G/EWvNlJfYK4GtQMztZIv9NCEu7ipH O1B4PeJ3C4i9GvFm9Rn5b7DGN4MV8K6UwRFVkZsR9OJDZh+rf8 d21Hi4rzvY6hRPSxLivdR891/FPb3Wlwf2ERtgCNWHfdtMHCOf p34W2UI7LyFR0quiwpyZn22UNKNbbRAQsPG3q45ujXaF3wKaIO jafTftFolBzVtsL4v/2Nd8qElxL22yLPlj+5hSqHDF+jQlfoOX RwsGqEFCEwBDjeXyekQoTgRC6O9+MLBr1tzZnMlaWxYyVgdAlA ptd7O
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jm94V197m19qI_v93TmdTWQ0SAk
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 18:09:48 -0000

--089e0158c7c43cdc7305057a0970
Content-Type: text/plain; charset=UTF-8

"Florian Weimer" :

> One more issue: The draft is silent on how to respond to an
inappropriate_fallback alert.

No, it is expressly a fatal alert. What else do you think would need to be
said?

Bodo

--089e0158c7c43cdc7305057a0970
Content-Type: text/html; charset=UTF-8


"Florian Weimer" <fweimer@redhat.com>:


> One more issue: The draft is silent on how to respond to an inappropriate_fallback alert.


No, it is expressly a fatal alert. What else do you think would need to be said?


Bodo




--089e0158c7c43cdc7305057a0970--


From nobody Wed Oct 15 11:09:54 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DB51A9036 for ; Wed, 15 Oct 2014 11:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlUC_Tds8Ofp for ; Wed, 15 Oct 2014 11:09:48 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D401A903A for ; Wed, 15 Oct 2014 11:09:47 -0700 (PDT)
Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) by mrelayeu.kundenserver.de (node=mreue001) with ESMTP (Nemesis) id 0M9B9x-1XSbZc16wH-00CNgn; Wed, 15 Oct 2014 20:09:45 +0200
Received: by mail-yk0-f169.google.com with SMTP id 10so810786ykt.0 for ; Wed, 15 Oct 2014 11:09:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.19.232 with SMTP id n68mr19569382yhn.27.1413396584214; Wed, 15 Oct 2014 11:09:44 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 11:09:42 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 11:09:42 -0700 (PDT)
In-Reply-To: <543E9FFA.5030102@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>
Date: Wed, 15 Oct 2014 20:09:42 +0200
Message-ID: 
From: Bodo Moeller 
To: Florian Weimer 
Content-Type: multipart/alternative; boundary=089e0163416e5439c005057a0950
X-Provags-ID: V02:K0:Fo9NhCOM0mN1SezlB4qrveBp63w8OD8FBEfKf9ONy+3 fZrCtCK2eq2j2I+yL9VDk60Jxh2W1zFvZ7Xo4XBQPf8rbYNbEZ Y9q9t14SUaMZcqmrn6fiddzVnVJdGBqaD1rUnJwCSXdPdbkdTu xvYeUY6ZwMpcWyc0WdiI9n3aORTOPDN2IrFvFBUjM7KcjDAHRJ g1M2sdWcq4K0Dlzbg/qXIUwt5+qYhWpfQdZxQhu/zL/IFZNueW MnnhSmW47yk9yg16ZsWGTwEyqtZjcq2l2MrwnyN3zLhFwYk20L HPJnNc2HjOpq3Nv4aXPUt5DYoH+ke0kLAnNqydMYvq6U9p+wDF her+2K0z1yUk4W0Hb0GdLtdBlPb2oUFD+kbxG9T1q1k5q6XvhT RDHNHUmjdtm8qTBuGGw9Sw7Fobc8g3LyLUbYi/lTIC/F/MPBox F7/xv
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TcVkE0gmtUNp4-jQdTjUBLPDog4
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 18:09:49 -0000

--089e0163416e5439c005057a0950
Content-Type: text/plain; charset=UTF-8

"Florian Weimer" :

> I'm concerned that a straightforward implementation of this new SCSV in
Firefox will introduce user-visible connection failures when the downgrade
is caused by a (likely spurious) networking event.

This is similar to spurious network failures if you didn't have fallback
retries at all. The details of how browsers do or do not retry in response
to network glitches certainly are out of score for this spec.

--089e0163416e5439c005057a0950
Content-Type: text/html; charset=UTF-8


"Florian Weimer" <fweimer@redhat.com>:


> I'm concerned that a straightforward implementation of this new SCSV in Firefox will introduce user-visible connection failures when the downgrade is caused by a (likely spurious) networking event.


This is similar to spurious network failures if you didn't have fallback retries at all. The details of how browsers do or do not retry in response to network glitches certainly are out of score for this spec.


--089e0163416e5439c005057a0950--


From nobody Wed Oct 15 11:09:55 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348391A9036 for ; Wed, 15 Oct 2014 11:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NieZTUdEj3zE for ; Wed, 15 Oct 2014 11:09:49 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFB21A902D for ; Wed, 15 Oct 2014 11:09:49 -0700 (PDT)
Received: from mail-yh0-f48.google.com (mail-yh0-f48.google.com [209.85.213.48]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0Lnlkd-1Y5XEr2wiV-00hrMP; Wed, 15 Oct 2014 20:09:47 +0200
Received: by mail-yh0-f48.google.com with SMTP id v1so833987yhn.35 for ; Wed, 15 Oct 2014 11:09:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.229.164 with SMTP id h34mr4008167yhq.199.1413396585479;  Wed, 15 Oct 2014 11:09:45 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 11:09:42 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 11:09:42 -0700 (PDT)
In-Reply-To: <543E9FFA.5030102@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>
Date: Wed, 15 Oct 2014 20:09:42 +0200
Message-ID: 
From: Bodo Moeller 
To: Florian Weimer 
Content-Type: multipart/alternative; boundary=001a11c1db2a67895105057a09fe
X-Provags-ID: V02:K0:SVHlqAr4dlCcn1Z4EI170w6mALi/aMs5r/DU7y/eyKC 37661GjXxBItqM0adgHj6Kjr6rS4Wo/8dq5tNvbwuFxg9lCmQ2 3MNIk6M5GTfLh9My745kyXyMa94JFDX2KF32MCGyg8i+X684tF 3xMdnc+CPVcQWRv03/5xF5BoVz1plkzM9qvmng3nWV3pdccy1O 20GmAwp3n5+Yolu6hXSKUAtdvD5dYjcO/aShz4MWzJrIwVEcgU YdAxnMrV32H7Frcnpa3HxUY865jhqoZw2dKNhMJwe97FBdvvSV WxzivnchBh+hCWDCYheHIrB0ugfy7ccCQ9M3QRgpUHnZyA8WOO pZ4fcUaxizzwB0dwrO4zMfbOXh2NPGPKDO7TxCkjwFgPV+vpiL i0PTH1sCMWZ6hvpACN8qnxrvXP342V2ODsFeuSw0hKcqaDxQ8/ oQHLb
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oCk7_Nlod5vUlOTxLniIRB6iZ3s
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 18:09:50 -0000

--001a11c1db2a67895105057a09fe
Content-Type: text/plain; charset=UTF-8

"Florian Weimer" :

> *) Deploying an SCSV-enabled browser to users on an intercepting network
will largely knock these users off the net (assuming that SCSV support is
widely deployed in public-facing TLS termination), so such attacks are
hopefully very isolated, or else it's not possible to deploy this feature
in browsers.

Thanks for the value proposition, by the way :-)

Preventing such attacks, of course, is what we consider a feature. Google
servers support the SCSV, and so does the Chrome browser; so we have the
required real-life experience indicating that deploying the SCSV is
practical.

Bodo

--001a11c1db2a67895105057a09fe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


"Florian Weimer" <fweimer@redhat.com>:


> *) Deploying an SCSV-enabled browser to users on an int=
ercepting network will largely knock these users off the net (assuming that=
 SCSV support is widely deployed in public-facing TLS termination), so such=
 attacks are hopefully very isolated, or else it's not possible to depl=
oy this feature in browsers.


Thanks for the value proposition, by the way :-)


Preventing such attacks, of course, is what we consider a fe=
ature. Google servers support the SCSV, and so does the Chrome browser; so =
we have the required real-life experience indicating that deploying the SCS=
V is practical.


Bodo


--001a11c1db2a67895105057a09fe--


From nobody Wed Oct 15 11:24:20 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8566D1A1AFA for ; Wed, 15 Oct 2014 11:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGBvaijFSlmL for ; Wed, 15 Oct 2014 11:24:15 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E116C1A90A3 for ; Wed, 15 Oct 2014 11:24:14 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id ge10so1556873lab.38 for ; Wed, 15 Oct 2014 11:24:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wXMn/G7W1sEuEWM7kjcE8RwUH/eRorBS5mmkzI6QKRw=; b=gbW4RIYPFeC0dJ0r/iiTvHzpbJNX1VWM853a2BdYACqmny2sHuD6/1D1dvWpXhsK3W xxNeUPjXdp7zFlJNFKiVGk9yd8QUcJV0jOpHNXxB5gMsMOTBJpml8k7csWjx7eHPUUXa NTPQMMAiK45oTPyqRm5CaQJZJe5WdDT2TwQaeioFxHMulwwcN7gLztltryxfOOrUEogP xBie4US4Dx+QDdk00iceuzJ0sd8zc58zo8WX9EGPbE2hQj0VmOFj4bekPjmlILt7Z5rV ebTVP3MLPWCAcu9SF6JYKr5fTPFx1EdRdfP/DsQn0pxmEe/v3nXtsX03C03dyk1xa1k7 av4A==
MIME-Version: 1.0
X-Received: by 10.112.94.133 with SMTP id dc5mr14162334lbb.11.1413397452974; Wed, 15 Oct 2014 11:24:12 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Wed, 15 Oct 2014 11:24:12 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com> 
Date: Wed, 15 Oct 2014 11:24:12 -0700
Message-ID: 
From: Martin Thomson 
To: Bodo Moeller 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5Cl0Uk6VCovel4yq7FnZePTsl-g
Cc: Florian Weimer , "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 18:24:16 -0000

On 15 October 2014 11:09, Bodo Moeller  wrote:
> Preventing such attacks, of course, is what we consider a feature. Google
> servers support the SCSV, and so does the Chrome browser; so we have the
> required real-life experience indicating that deploying the SCSV is
> practical.

And I'd like to add that the SCSV has been in Firefox Nightly for a
while now.  We got some early reports of problems because of the way
we were reacting to spurious fallbacks, but that has been addressed
and I've not seen any subsequent reports of problems.

This is a strictly good feature for Firefox users.  The alternative
(disable insecure version intolerant fallback entirely) is completely
untenable for us.  If you personally don't like that, I've a patch
that allows users to disable fallback.  That should be landing
shortly.


From nobody Wed Oct 15 11:26:52 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA07D1A90AC for ; Wed, 15 Oct 2014 11:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8AtIB4b_cDY for ; Wed, 15 Oct 2014 11:26:42 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7A4B1A1AFA for ; Wed, 15 Oct 2014 11:26:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=Gc5pHZxb/plPMt/YPL47NjMNR7AONYGLM4lhnBoQi2Q=;  b=GAw+rXdyMjE1GqDJwaFAyOdDmlbbXqpaPqXU2+jlx/ultHDrLKFO72vOHK5OvKbv8VsJ76dPmveytwuoDg4vHe8gyaJMwpUB7Q4RhubSdVVz+JQiTj2cPQ1NWZL/+83ORkE4ryp+DN5I57Jm0DpcadwNkzjZKZLKDHcbUXERJP0=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XeTHO-00015l-Mf; Wed, 15 Oct 2014 20:26:34 +0200
Message-ID: <543EBC5D.5010805@polarssl.org>
Date: Wed, 15 Oct 2014 20:26:37 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Bodo Moeller , Florian Weimer 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E95AE.1030300@redhat.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NynWEx3jjvKR-1nvOhXfnyXG6q4
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 18:26:43 -0000

On 15/10/2014 20:09, Bodo Moeller wrote:
> "Florian Weimer" :
> 
>> One more issue: The draft is silent on how to respond to an
> inappropriate_fallback alert.
> 
> No, it is expressly a fatal alert. What else do you think would need to be
> said?
> 
Maybe the draft could mention that after aborting the downgraded connection due
to this fatal alert, clients may want to retry with the original version?

Manuel.


From nobody Wed Oct 15 11:52:33 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295191A90C7 for ; Wed, 15 Oct 2014 11:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.551
X-Spam-Level: 
X-Spam-Status: No, score=-8.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Be3z-xLWYbZE for ; Wed, 15 Oct 2014 11:52:19 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C3C1A90DD for ; Wed, 15 Oct 2014 11:52:19 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 4B10B5520D; Wed, 15 Oct 2014 20:52:17 +0200 (CEST)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 00AB941B9D; Wed, 15 Oct 2014 20:52:16 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id EE6371AEDF; Wed, 15 Oct 2014 20:52:16 +0200 (CEST)
In-Reply-To: <543E2D81.1050700@redhat.com>
To: Florian Weimer 
Date: Wed, 15 Oct 2014 20:52:16 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141015185216.EE6371AEDF@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DKATqzuLb5c2AQ3e4NZ1ouM_2pg
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 18:52:24 -0000

Florian Weimer wrote:
> Joseph Salowey (jsalowey) wrote:
>>
>> This is an announcement for the working group last call for
>> draft-ietf-tls-downgrade-scsv-00.  Please review the document
>> and send your comments to the list by Friday, October 17, 2014.
> 
> I'm strongly against this proposal. 

I'm also strongly opposed to this proposal, because it does not provide
any value--there is not one single *additional* TLS handshake that it
will make succeed, instead, the only thing that this proposal will
provide is either zero benefit or fatal interop failure, i.e. it
if there is any result from it it will be headaches to users, sysadmins
and helpdesks.

This proposal is as far opposite from the spirit of the IETF as
one can possibly get.


What we would need instead of this proposal, is one that will

  (1) make more TLS handshakes succeed

  (2) make more TLS handshakes succeed with new protocol features

  (3) make more TLS handshakes succeed with new protocol features
      for regular app clients that do not have re-connect fallback in place,
      and _without_ interfering with conservative ClientHellos that these
      clients use to maintain interop with old, "broken" servers out there.


The "downgrade-scsv" has the effective semantics of
"kick me if you can read this", which is pretty silly on my scorecard.


A reasonable alternative SCSV would have the semantics
"Dear Server, I'm a new, full-featured client and would really like
to send you a full-featured ClientHello, but didn't dare doing as
the first message on the connection because of all the old broken
servers out there which choke on feature-rich ClientHellos".

And a new Server's response to such an SCSV should be to
respond with a ServerHello+ServerHelloDone which carries the SCSV
in the ServerHello.cipher_suite = SCSV, which the client will
recognize and understand as an invitation to send the desired
full-featured ClientHello (on the very same existing connection
transparently).


-Martin


From nobody Wed Oct 15 12:02:57 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DCB1A9137 for ; Wed, 15 Oct 2014 12:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-zK5o5IkyHK for ; Wed, 15 Oct 2014 12:02:52 -0700 (PDT)
Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B541A914C for ; Wed, 15 Oct 2014 12:02:52 -0700 (PDT)
Received: by mail-yh0-f53.google.com with SMTP id b6so891105yha.12 for ; Wed, 15 Oct 2014 12:02:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LRFUOapUcOMK5hpYppnLX5dkUg+H+9GBU7AgUy4SZ1M=; b=cgUcpxylinj1xBY4MhAKeFcE6asvECVpHB5tm8n6obMXdFR9cy3lk+qUQLKOWXvyp1 CkO4qTGlYJWPmAyX5W8ZdR0OfsOK3cAnb6X7EVhA94VFYNgdjPY27KDLLw5F35ueky8T yygviSi2guKOw/BDsd9haMyUKsd6FddYE0o64vFnrMrSOyO3dI7fmcvyoGGzg4Gdu9iv pS2BDRUlhcIX3p1AUTDv4aRR54+Gpimj0mUgk2et2p8hVuiaJ1O4oHZtGn2GidPAcZO8 JrlmHAG6WKgpfUpxOMJOvXc5l0oD8PNcQcKah2uI9Axj16SjNrbtw2saTuhrae6P6gkd wZDA==
MIME-Version: 1.0
X-Received: by 10.236.103.170 with SMTP id f30mr12327605yhg.4.1413399771736; Wed, 15 Oct 2014 12:02:51 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Wed, 15 Oct 2014 12:02:51 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Wed, 15 Oct 2014 12:02:51 -0700 (PDT)
In-Reply-To: <20141015185216.EE6371AEDF@ld9781.wdf.sap.corp>
References: <543E2D81.1050700@redhat.com> <20141015185216.EE6371AEDF@ld9781.wdf.sap.corp>
Date: Wed, 15 Oct 2014 12:02:51 -0700
Message-ID: 
From: Watson Ladd 
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=001a113321ae51f0a005057ac75b
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8Pizq5qNlyWWZxKBh8gOmfU_Ut8
Cc: Florian Weimer , tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 19:02:55 -0000

--001a113321ae51f0a005057ac75b
Content-Type: text/plain; charset=UTF-8

On Oct 15, 2014 11:52 AM, "Martin Rex"  wrote:
>
> Florian Weimer wrote:
> > Joseph Salowey (jsalowey) wrote:
> >>
> >> This is an announcement for the working group last call for
> >> draft-ietf-tls-downgrade-scsv-00.  Please review the document
> >> and send your comments to the list by Friday, October 17, 2014.
> >
> > I'm strongly against this proposal.
>
> I'm also strongly opposed to this proposal, because it does not provide
> any value--there is not one single *additional* TLS handshake that it
> will make succeed, instead, the only thing that this proposal will
> provide is either zero benefit or fatal interop failure, i.e. it
> if there is any result from it it will be headaches to users, sysadmins
> and helpdesks.
>
> This proposal is as far opposite from the spirit of the IETF as
> one can possibly get.
>
>
> What we would need instead of this proposal, is one that will
>
>   (1) make more TLS handshakes succeed
>
>   (2) make more TLS handshakes succeed with new protocol features
>
>   (3) make more TLS handshakes succeed with new protocol features
>       for regular app clients that do not have re-connect fallback in
place,
>       and _without_ interfering with conservative ClientHellos that these
>       clients use to maintain interop with old, "broken" servers out
there.
>
>
> The "downgrade-scsv" has the effective semantics of
> "kick me if you can read this", which is pretty silly on my scorecard.
>
>
> A reasonable alternative SCSV would have the semantics
> "Dear Server, I'm a new, full-featured client and would really like
> to send you a full-featured ClientHello, but didn't dare doing as
> the first message on the connection because of all the old broken
> servers out there which choke on feature-rich ClientHellos".
>
> And a new Server's response to such an SCSV should be to
> respond with a ServerHello+ServerHelloDone which carries the SCSV
> in the ServerHello.cipher_suite = SCSV, which the client will
> recognize and understand as an invitation to send the desired
> full-featured ClientHello (on the very same existing connection
> transparently).

This proposal looks to me to be clearly better theoretically. It's more
robust in the face of transient network issues. OTOH, if the practical
difference is minor, I'd rather get done sooner than later. I'm also by no
means knowledgeable about the impact on stateful firewalls expecting to see
TLS with a particular flow, or if this even is an issue.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/
tls

--001a113321ae51f0a005057ac75b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Oct 15, 2014 11:52 AM, "Martin Rex" <mrex@sap.com> wrote:

>

> Florian Weimer wrote:

> > Joseph Salowey (jsalowey) wrote:

> >>

> >> This is an announcement for the working group last call for
> >> draft-ietf-tls-downgrade-scsv-00.=C2=A0 Please review the doc=
ument

> >> and send your comments to the list by Friday, October 17, 201=
4.

> >

> > I'm strongly against this proposal.

>

> I'm also strongly opposed to this proposal, because it does not pr=
ovide

> any value--there is not one single *additional* TLS handshake that it<=
br>
> will make succeed, instead, the only thing that this proposal will

> provide is either zero benefit or fatal interop failure, i.e. it

> if there is any result from it it will be headaches to users, sysadmin=
s

> and helpdesks.

>

> This proposal is as far opposite from the spirit of the IETF as

> one can possibly get.

>

>

> What we would need instead of this proposal, is one that will

>

> =C2=A0 (1) make more TLS handshakes succeed

>

> =C2=A0 (2) make more TLS handshakes succeed with new protocol features=


>

> =C2=A0 (3) make more TLS handshakes succeed with new protocol features=


> =C2=A0 =C2=A0 =C2=A0 for regular app clients that do not have re-conne=
ct fallback in place,

> =C2=A0 =C2=A0 =C2=A0 and _without_ interfering with conservative Clien=
tHellos that these

> =C2=A0 =C2=A0 =C2=A0 clients use to maintain interop with old, "b=
roken" servers out there.

>

>

> The "downgrade-scsv" has the effective semantics of

> "kick me if you can read this", which is pretty silly on my =
scorecard.

>

>

> A reasonable alternative SCSV would have the semantics

> "Dear Server, I'm a new, full-featured client and would reall=
y like

> to send you a full-featured ClientHello, but didn't dare doing as<=
br>
> the first message on the connection because of all the old broken

> servers out there which choke on feature-rich ClientHellos".

>

> And a new Server's response to such an SCSV should be to

> respond with a ServerHello+ServerHelloDone which carries the SCSV

> in the ServerHello.cipher_suite =3D SCSV, which the client will

> recognize and understand as an invitation to send the desired

> full-featured ClientHello (on the very same existing connection

> transparently).


This proposal looks to me to be clearly better theoretically=
. It's more robust in the face of transient network issues. OTOH, if th=
e practical difference is minor, I'd rather get done sooner than later.=
 I'm also by no means knowledgeable about the impact on stateful firewa=
lls expecting to see TLS with a particular flow, or if this even is an issu=
e.

>

>

> -Martin

>

> _______________________________________________

> TLS mailing list

>TLS@ietf.org

>https://www.ietf.=
org/mailman/listinfo/tls


--001a113321ae51f0a005057ac75b--


From nobody Wed Oct 15 12:19:50 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF311A9138 for ; Wed, 15 Oct 2014 12:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.938
X-Spam-Level: 
X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYl5ygQUBl_l for ; Wed, 15 Oct 2014 12:19:46 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2708F1A1B1A for ; Wed, 15 Oct 2014 12:19:46 -0700 (PDT)
Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0MF4EF-1XOrBz0ZRb-00GIbN; Wed, 15 Oct 2014 21:19:44 +0200
Received: by mail-yh0-f47.google.com with SMTP id c41so911162yho.6 for ; Wed, 15 Oct 2014 12:19:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.22.228 with SMTP id t64mr6928456yht.164.1413400782573; Wed, 15 Oct 2014 12:19:42 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 12:19:42 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 12:19:42 -0700 (PDT)
In-Reply-To: <20141015185216.EE6371AEDF@ld9781.wdf.sap.corp>
References: <543E2D81.1050700@redhat.com> <20141015185216.EE6371AEDF@ld9781.wdf.sap.corp>
Date: Wed, 15 Oct 2014 21:19:42 +0200
Message-ID: 
From: Bodo Moeller 
To: Martin Rex 
Content-Type: multipart/alternative; boundary=e89a8f642a9892179405057b03e2
X-Provags-ID: V02:K0:G1yJ85HBUyLrkqZSjU/efajovBAPGZfw22/Kb1AEMQH Ak8FmmgqmlynXSpN5HUiMPRbgxvmbQMzenRGZmeMU7KyoSwAbc ZkLNerJ4Hbs/K7tm7ETWoHP9uQ5T/X1oeaxtqGDhQx38zuKyLs IEUxRPJQxef71CgdtrnSQvqdYEaAZ3MPaOyf2UhAMtCwlla4ld nGkNiJOQu12B2WA6BwrunupCk8lnu0wEEaU1YBp160+7Xogw8l dVTKa8gaIYRe70oTLjpFDqL70BU1zU7b2QutT94DHVkoppqRLJ rT1/aRw9rX2G6Ml4O/ZIGEu1W+4W1KOARiyYFovwJ7HgbrxQ7/ Lqq49noMZk+eVw0wCQCKhP9niL4Uur/1HkOhFdFguDZiqWNpKk i2+T26n6c6IwRXPDMva7a4jKT53TuHhT9NuQ9FsEGtckr1thJU PszAH
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fOL4-5bbf6eHTlyWEbAXYAwf1JI
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 19:19:48 -0000

--e89a8f642a9892179405057b03e2
Content-Type: text/plain; charset=UTF-8

"Martin Rex" :

> I'm also strongly opposed to this proposal, because it does not provide
> any value--there is not one single *additional* TLS handshake that it
> will make succeed,
[...]

> The "downgrade-scsv" has the effective semantics of
> "kick me if you can read this", which is pretty silly on my scorecard.
>
>
> A reasonable alternative SCSV would have the semantics
> "Dear Server, I'm a new, full-featured client and would really like
> to send you a full-featured ClientHello, but didn't dare doing as
> the first message on the connection because of all the old broken
> servers out there which choke on feature-rich ClientHellos".
>
> And a new Server's response to such an SCSV should be to
> respond with a ServerHello+ServerHelloDone which carries the SCSV
> in the ServerHello.cipher_suite = SCSV, which the client will
> recognize and understand as an invitation to send the desired
> full-featured ClientHello (on the very same existing connection
> transparently).

Improving interoperability per se certainly is not a goal of our spec
(instead, it's all about breaking interoperability with attackers if you
will).

That doesn't mean that avoiding the need for fallback retries isn't a
worthy goal, it just is completely orthogonal to what TLS_FALLBACK_SCSV
does. We give you a spec that you can deploy right to gain actual security
advantages (unless your clients never do fallback retries), where the
solution you sketch would be much more involved.

Once anything like what you propose gets successfully rolled out, there
would be no more need to send our SCSV, and the (simple!) server-side logic
would then lie dormant. However I think it's pretty clear that that day is
still pretty far away -- certainly far enough to warrant taking other
measures of protection.

Your claim that TLS_FALLBACK_SCSV
"does not provide any value" appears blatantly untrue, unless you don't
recognize preventing demonstrated attacks as "value".

Bodo

--e89a8f642a9892179405057b03e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


"Martin Rex" <m=
rex@sap.com>:


> I'm also strongly opposed to this proposal, because=
 it does not provide

> any value--there is not one single *additional* TLS handshake that it<=
br>
> will make succeed,

[...]


> The "downgrade-scsv" has the effective semant=
ics of

> "kick me if you can read this", which is pretty silly on my =
scorecard.

>

>

> A reasonable alternative SCSV would have the semantics

> "Dear Server, I'm a new, full-featured client and would reall=
y like

> to send you a full-featured ClientHello, but didn't dare doing as<=
br>
> the first message on the connection because of all the old broken

> servers out there which choke on feature-rich ClientHellos".

>

> And a new Server's response to such an SCSV should be to

> respond with a ServerHello+ServerHelloDone which carries the SCSV

> in the ServerHello.cipher_suite =3D SCSV, which the client will

> recognize and understand as an invitation to send the desired

> full-featured ClientHello (on the very same existing connection

> transparently).


Improving interoperability per se certainly is not a goal of=
 our spec (instead, it's all about breaking interoperability with attac=
kers if you will).


That doesn't mean that avoiding the need for fallback re=
tries isn't a worthy goal, it just is completely orthogonal to what TLS=
_FALLBACK_SCSV does. We give you a spec that you can deploy right to gain a=
ctual security advantages (unless your clients never do fallback retries), =
where the solution you sketch would be much more involved.


Once anything like what you propose gets successfully rolled=
 out, there would be no more need to send our SCSV, and the (simple!) serve=
r-side logic would then lie dormant. However I think it's pretty clear =
that that day is still pretty far away -- certainly far enough to warrant t=
aking other measures of protection.


Your claim that TLS_FALLBACK_SCSV 

"does not provide any value" appears blatantly untrue, unless you=
 don't recognize preventing demonstrated attacks as "value".<=
/p>

Bodo


--e89a8f642a9892179405057b03e2--


From nobody Wed Oct 15 12:27:40 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667271A885A for ; Wed, 15 Oct 2014 12:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.638
X-Spam-Level: 
X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2W8U_OfEG_S for ; Wed, 15 Oct 2014 12:27:37 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014D21A1B1A for ; Wed, 15 Oct 2014 12:27:37 -0700 (PDT)
Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) by mrelayeu.kundenserver.de (node=mreue001) with ESMTP (Nemesis) id 0MZ5db-1XiaqT406V-00ViXU; Wed, 15 Oct 2014 21:27:35 +0200
Received: by mail-yk0-f169.google.com with SMTP id 10so875328ykt.0 for ; Wed, 15 Oct 2014 12:27:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.110.35 with SMTP id t23mr16979343yhg.126.1413401253724;  Wed, 15 Oct 2014 12:27:33 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 12:27:33 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 12:27:33 -0700 (PDT)
In-Reply-To: <543EBC5D.5010805@polarssl.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E95AE.1030300@redhat.com>  <543EBC5D.5010805@polarssl.org>
Date: Wed, 15 Oct 2014 21:27:33 +0200
Message-ID: 
From: Bodo Moeller 
To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= 
Content-Type: multipart/alternative; boundary=001a1133358aa7528705057b1fc4
X-Provags-ID: V02:K0:2wBHQ34oQukOcZW8JEpGF7eRwe2kA+bIxTEOXDpRTkx oRIVTCxFfO8ViBDLbX4SB8RPEYRyfuAJO302HGa/iw0w1Eq7CU rc82eCwkmYQukebTffzOJ/va2V7QzEqCJyJ+Z47c8m6+8kFQrU +VkfsLS1Quc4ji8VfmGy84Jl5u5oJmLRBgFbNQnB8xBOaoqMhU LKfNP580WiP42dBiKfMdM7Bu1nv8/5441TOWwn/1kScyRqN+ql nXvmvcSRPzz++Aewd6Usz7NHQKhdPx3wHxWuQIFFyfIfIi7uBY /NxXwu+PEELjqIg/YvspML3hq6gxNGK5i91CxvzNF55NxY0F/P VLY4HDUiiFXBWP5P77umXLcvAgLKNlYgXlmLXx2cCFNQ371kA7 0k5VHhX3on1YtJ2UJfIO8HgoT5qBcByn/5kMGRJEt37zi7TfmZ NC33I
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7MtxvsIA4taIPBDDm2VHydfm8Mk
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 19:27:38 -0000

--001a1133358aa7528705057b1fc4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Manuel P=C3=A9gouri=C3=A9-Gonnard" :

> Maybe the draft could mention that after aborting the downgraded
connection due
> to this fatal alert, clients may want to retry with the original version?

Hm -- probably probably not in this form as the specification doesn't say
that or how you should retry, but we could point out that network glitches
could result in seeing the alert on a fallback retry (so that implementors
can take this into account for whatever it is that they need to achieve).

--001a1133358aa7528705057b1fc4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Manuel P=C3=A9gouri=C3=A9-Gonnard" <mpg@polarssl.org>:


> Maybe the draft could mention that after aborting the d=
owngraded connection due

> to this fatal alert, clients may want to retry with the original versi=
on?


Hm -- probably probably not in this form as the specificatio=
n doesn't say that or how you should retry, but we could point out that=
 network glitches could result in seeing the alert on a fallback retry (so =
that implementors can take this into account for whatever it is that they n=
eed to achieve).




--001a1133358aa7528705057b1fc4--


From nobody Wed Oct 15 13:39:26 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582C51ACD1C for ; Wed, 15 Oct 2014 13:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvQL7JRzRFkg for ; Wed, 15 Oct 2014 13:39:20 -0700 (PDT)
Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749FA1ACD05 for ; Wed, 15 Oct 2014 13:39:20 -0700 (PDT)
Received: by mail-oi0-f51.google.com with SMTP id h136so1616189oig.24 for ; Wed, 15 Oct 2014 13:39:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YewGF65Zhj4BcNoDfT5j7ECFHedqIotl08YFYYH2Omc=; b=PYC+E1CxFYXo40ejT10PcqkMv7KLgePzQ1NJzXUKf8P5HwD2jNaQLr60Cb+l2tPQFG 9tyHFnlI8OAa9Xmi0qCcT6F+4GoNRwq7/JOcMNpzj/oPUSEsXm/3in+YQOMEqhhKARYS SqO1yjko0Kkk5O6iPgBuGWI2JIR4SD8QaSUH5qX6lsU+Prw1vv/K5ncGzf5g1s8U9Jyk ZDkJHhia/BjMyA664bh96wLq8lR0dLMwBq67aWjaC2r/pGNEQ3A6N8VJn2P14rBxB0tj 3h0zWPaocmjF6g+NziNZ9am1Z68hVZPLnxJGY4XMo3o3Or8D086GlCIwzzd3b2UwiuLM Jt8Q==
X-Gm-Message-State: ALoCoQk92br47Y2aKMq0np/l+wT/S+i936MZ6EeVd0D5x6VXWRjgF/dpcbBFV7r46/Cgq20rh/u4
MIME-Version: 1.0
X-Received: by 10.202.168.65 with SMTP id r62mr12405818oie.26.1413405559919; Wed, 15 Oct 2014 13:39:19 -0700 (PDT)
Received: by 10.76.93.9 with HTTP; Wed, 15 Oct 2014 13:39:19 -0700 (PDT)
In-Reply-To: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
Date: Wed, 15 Oct 2014 13:39:19 -0700
Message-ID: 
From: Brian Smith 
To: "Joseph Salowey (jsalowey)" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dEoNDkcseCVFnAChdly0Epwdayw
Cc: "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 20:39:22 -0000

On Thu, Sep 25, 2014 at 9:00 PM, Joseph Salowey (jsalowey)
 wrote:
> This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your comments to the list by Friday, October 17, 2014.

It seems like the draft should also advise clients that they MUST NOT
do the False Start optimization if the server does not choose the
maximum version of TLS that they support. For example, if the server
chooses a version less than ClientHello.client_version, or if the
client sent the TLS_FALLBACK_SCSV, then the client MUST NOT false
start. Currently the draft says nothing about this. Because of False
Start, there are several downgrades that are still possible even with
the current downgrade-SCSV-enabled Chrome and Firefox, for example.

1. During a False Start handshake, the MitM can remove the
TLS_FALLBACK_SCSV from the ClientHello, so that the server cannot
detect the version downgrade. The client will only be able to detect
this tampering once it has processed the server's Finished message.
But, by then, it has already sent application data using the
downgraded version.

2. Similarly, the MitM can tamper with ClientHello.client_version in a
ClientHello regardless of whether it has the TLS_FALLBACK_SCSV in it,
and a client that does the False Start optimization won't notice the
tampering until after it has sent some application data.

3. Even without tampering with TLS_FALLBACK_SCSV or
ClientHello.client_version, a MitM can easily degrade the cryptography
on a connection. For example, let's say a server supports ECDHE with
P-256 and DHE with 1024-bit keys. A P-256 key is much stronger than a
DHE-1024 key. If an attacker removes P-256 from the client's
supported_curves extension, then the server will choose a DHE-1024 key
in the handshake, even with TLS 1.2. This type of downgrade could have
a much bigger effect than a downgrade from TLS 1.2 to TLS 1.1.

In all these cases, the server won't process the client's application
data, because the server will detect the tampering before processing
it (because it processes the client's Finished message before it
processes the application data). But in theory there may be attacks
where just sending the initial application data in a downgraded
version would be a security problem. For example, when it is clear to
everybody that SHA-1 is broken, non-secure downgrades from TLS 1.2 to
TLS 1.1 alone will be a severe security problem. If these attacks are
out of scope, then the document should say so. Otherwise, they should
be addressed.

In summary, the way it is defined, the downgrade SCSV is only helpful
in preventing a limit number of unspecified downgrade attacks when
used in conjunction with False Start. Also, the draft is based on the
premise that preventing version downgrade is useful for preventing
some cryptographic attacks, but it does not substantiate that. POODLE
and BEAST are evidence that the mechanism helps for some attacks. But,
is this mechanism actually effective for preventing any other class of
attacks, other than TLS 1.1 -> TLS 1.0 -> SSL 3.0 downgrade for CBC
cipher suites? The answer to this should be in the security
considerations.

I don't think it makes sense to consider False Start out of scope for
this, because all the browsers that are doing the non-secure version
fallback are also doing the False Start optimization.

Cheers,
Brian


From nobody Wed Oct 15 13:42:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401DD1ACD05 for ; Wed, 15 Oct 2014 13:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oF7InzB53pp for ; Wed, 15 Oct 2014 13:42:19 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72DD1A88F3 for ; Wed, 15 Oct 2014 13:42:19 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id vb8so1756842obc.17 for ; Wed, 15 Oct 2014 13:42:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iyHjlhLfGLNsRybJtfb0eMaxCUtGFeN6uWCcNAcSn3k=; b=lgV6eICoIMhueFjjPIpQvbFsdcBVOCQV/6anrnvJfszRy/ddWPnge2VPwPNNkoTkJz RxC5maxlPAHttuV4KKcW2p7DnHbPX8RhpJHOUHAsaJtZYgCtBUeSd7LsOnbARvZeJEOh lYcczPH3o2KKIdUBXn+1CfiKFs21ktScMicN57ONIKNmBgQQkS/Dw7l+yWl3Wh/aMT3J OmmwGoqugZGqDvt3aDMnwpv2dDFOZRxBDfcpgxLZdE+9lts3FiHMq1Fe+bEgyxvgxoym Napb0C58nA7C4SLmb/B1aYinUIRdTk1KX8DAUhg+3KOYcH1vP84mh4uwUyK1I2JkgQg1 nmbQ==
X-Gm-Message-State: ALoCoQnW/IepUVjY7mPTR9ZljKy/yvtS+lkpzyH4bDrMKg2HOhdf2a2q2YhFl22FC9KAc3jZsx3/
MIME-Version: 1.0
X-Received: by 10.60.16.2 with SMTP id b2mr2946446oed.82.1413405739181; Wed, 15 Oct 2014 13:42:19 -0700 (PDT)
Received: by 10.76.93.9 with HTTP; Wed, 15 Oct 2014 13:42:18 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <20141015140158.41a1faf8@pc.my-domain> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com>
Date: Wed, 15 Oct 2014 13:42:18 -0700
Message-ID: 
From: Brian Smith 
To: "Salz, Rich" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/16h4wjI2gQAVhwLkS3y0_OBbm-A
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 20:42:21 -0000

On Wed, Oct 15, 2014 at 5:19 AM, Salz, Rich  wrote:
>> Can you quantify that tradeoff? How many devices are there really out th=
ere
>> that would break? I'd like to have this discussions with hard numbers.
>
> We (Akamai) see less than 1% SSLv2 and SSLv3 traffic globally and it's co=
ncentrated to a few particular clients.  Those clients are important to som=
e customers. They want modern browsers to be protected, by not falling back=
 to SSLv3, but they don't want to cut off those legacy clients.  SCSV fallb=
ack solves that problem.

That problem is also solved by the browsers simply not doing the
non-secure fallback to SSLv3.

> It also will solve a problem when some browsers try to use
> TLS 1.3 but servers haven't been updated.

If TLS 1.3 is still planning to use the version negotiation mechanism
to negotiate TLS 1.3, then that's a defect in TLS 1.3, for this
reason. That defect should be addressed so that the downgrade SCSV
will be a non-issue for TLS 1.3.

Cheers,
Brian


From nobody Wed Oct 15 14:14:00 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29941ACD96 for ; Wed, 15 Oct 2014 14:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXltpjSBAFp1 for ; Wed, 15 Oct 2014 14:13:54 -0700 (PDT)
Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79391ACD8B for ; Wed, 15 Oct 2014 14:13:53 -0700 (PDT)
Received: by mail-oi0-f48.google.com with SMTP id g201so1651218oib.35 for ; Wed, 15 Oct 2014 14:13:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OHSfZ8QivRgL2B8/nxw1b0jeJqfr0CJs6f1REQQV71s=; b=Kwo++krudovAHsf3Bd9zW8/iBw84JZLae/5hZMpgd8hFhPykgx7ol9GkvjKvixE3L9 aM9RsgGL58ydLjYAcpNcQlVMNYsf+bHy9eymvMGKNhEbttr0icm620fGK7/kwjrvYIlM rAnWgoPorYE/4O1pVIQcXqdO0QIiohITi3+AplIzt8HLVsg79GWWrmFhM+jPTrUCx3EL KHVNKZetGmAjhgqLT3RcpbfbW46ZUFxy77ybMG56lBZ2wB25I839NDUE8skp4ce9aXxn 70wDpUAm1XKdf0HsUzIL8YxYhPn1PZaw59IOQ25I//Stdso8wG4SECt5QmgasV1uA5/P zKMQ==
X-Gm-Message-State: ALoCoQnGK/SCXT+uKaiYwg8mzrdtEb9RF0ur+HEMwPccCPT7Ts7D9ck9NNLUmI3dv6jtOlZHreeH
MIME-Version: 1.0
X-Received: by 10.183.1.7 with SMTP id bc7mr13282626obd.32.1413407633240; Wed, 15 Oct 2014 14:13:53 -0700 (PDT)
Received: by 10.76.93.9 with HTTP; Wed, 15 Oct 2014 14:13:53 -0700 (PDT)
In-Reply-To: <543E9FFA.5030102@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>
Date: Wed, 15 Oct 2014 14:13:53 -0700
Message-ID: 
From: Brian Smith 
To: Florian Weimer 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dygyDh37uGkLf3OyZdlSXfdBnHw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 21:13:59 -0000

On Wed, Oct 15, 2014 at 9:25 AM, Florian Weimer  wrote:
> I'm concerned that a straightforward implementation of this new SCSV in
> Firefox will introduce user-visible connection failures when the downgrade
> is caused by a (likely spurious) networking event.

First, Mozilla publishes some data regarding non-secure version
fallback at [1]. (The UI is terrible, but there is an option to get
the raw data in tabular form on the right hand side of the page). You
can see the key for that data in the source code at [2].

Anyway, Firefox needs to stop doing the non-secure version fallback in
the case of network failures. The overwhelming majority of TLS 1.2 ->
TLS 1.1 fallbacks in Firefox are due to server closing the connection
during the handshake. Probably in the vast majority of those cases,
the closed connection is not actually indicating version intolerance.
The second most common case of fallback is receiving a RST. Again, the
vast majority of those RSTs are probably not actually caused by
version intolerance. These two conditions make up about 99% of the
reason for fallback in Firefox.

The problem is there are a very small number of servers that DO
indicate intolerance by closing the connection or with a RST. However,
I also agree with the others that say that it doesn't make sense for
browsers to ask every server to implement the downgrade SCSV to be
safe, because browsers don't want to break compatibility with this
tiny minority of old, broken servers.

My understanding is that the Chrome web browser is currently
experimenting in pre-release versions with not doing the non-secure
fallback from TLS 1.0 to SSL 3.0. I think all browsers should extend
that experiment to disabling the non-secure fallback mechanism
completely.

In particular, browsers should disable the non-secure fallback
mechanism completely before TLS 1.3 gets deployed, so that the TLS 1.3
design doesn't become unnecessarily reliant on the non-secure fallback
mechanism for compatibility. Otherwise, we may never be able to remove
it.

Cheers,
Brian

[1] http://telemetry.mozilla.org/#filter=release%2F32%2FSSL_TLS12_INTOLERANCE_REASON_POST
[2] https://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSIOLayer.cpp?rev=916f2837201c#1047


From nobody Wed Oct 15 16:40:31 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9531ACE79 for ; Wed, 15 Oct 2014 16:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGZ2_oNna1vU for ; Wed, 15 Oct 2014 16:40:28 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123C11ACE0E for ; Wed, 15 Oct 2014 16:40:28 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9FNeQbq005074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 15 Oct 2014 23:40:27 GMT
Received: from hermes-fe-2.easd.brm.oracle.com (hermes-fe-2.easd.brm.oracle.com [10.79.248.11]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9FNeQl3021464 for ; Wed, 15 Oct 2014 23:40:26 GMT
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII
Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by hermes-fe-2.easd.brm.oracle.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPSA id <0NDI00555F3C7400@hermes-fe-2.easd.brm.oracle.com> for tls@ietf.org; Wed, 15 Oct 2014 16:40:26 -0700 (PDT)
Date: Wed, 15 Oct 2014 16:40:24 -0700
From: Chris Newman 
To: tls@ietf.org
Message-id: <54B025040D4F68B1E49919B8@nifty-silver.us.oracle.com>
In-reply-to: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> <20141004033546.GG13254@mournblade.imrryr.org> <20141002175446.6EB7B1AEA6@ld9781.wdf.sap.corp>
References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/esKZ7JiGOMacIBBIWWY3LJ8jhNc
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 23:40:30 -0000

I agree with this:

--On October 4, 2014 3:35:47 +0000 Viktor Dukhovni 
wrote:
> Well, I for one am not.   Disabling RC4 does more harm than good
> with opportunistic TLS.  A far better approach in that case is to
> de-priorioritize it.  Giving some check-list enforcing clue-less
> auditor the ammunition to harass users into counter-productive
> "security" measures is not my idea of progress.
> ...
> Not all applications face the same risks, and removing RC4 will some
> applications *less* secure at least some of the time.

As an implementer of a product with TLS/SSL support, I will ignore the three
MUST/MUST NOT statements in this draft. As long as the SSL/TLS library I use
supports RC4, I'm going to support RC4. And I'll be reluctant to upgrade to an
SSL/TLS library that doesn't support RC4 for fear of breaking customer
interoperability and forcing opportunistic connections to clear text.

I believe the goal should be to replace RC4 usage in the real world with use of
stronger cipher suites. I do not believe the current draft will advance that
goal. Statements similar to the single-DES advice in RFC 5469 may advance that
goal. Here are other statements that may advance that goal:

* SSL/TLS software MUST prefer stronger cipher suites (presently AES and 3DES)
over RC4.

* SSL/TLS libraries MUST disable RC4 cipher suites by default. An application
MUST make an explicit SSL/TLS library API call to enable RC4 cipher suites if
they are needed for backwards compatibility.

* SSL/TLS software MUST disable RC4 cipher suites when TLS 1.1 or 1.2 are
negotiated and SHOULD disable RC4 cipher suites by default when earlier
versions are negotiated. For an opportunistic security transmission, such as
for SMTP relay (RFC 3207), RC4 MAY be used as a last resort for
interoperability prior to fallback to transmission without SSL/TLS.

* User agents that employ SSL/TLS for security MUST NOT indicate the connection
is secure when RC4 is used. For example, a web browser that displayed a lock
icon when an RC4 cipher suite was used would fail to comply with this
requirement.

		- Chris


From nobody Wed Oct 15 21:08:47 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7D81A0151 for ; Wed, 15 Oct 2014 21:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPg5flIsXoe5 for ; Wed, 15 Oct 2014 21:08:40 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D771A0054 for ; Wed, 15 Oct 2014 21:08:39 -0700 (PDT)
Received: by mail-la0-f47.google.com with SMTP id pv20so2168322lab.6 for ; Wed, 15 Oct 2014 21:08:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=55a24kDaDAstkEZfu5RFxPvDf0cIyqZW+97mkijn5zw=; b=ZNvLfABUWxX4C0Ty2KIHJysAAhZe539rmv/9akzXCIYWZJOzN2ilBhyDxZ03fwjtAC qhJ6cnAN9w3BJp6LkmRynhBBJQj2kfxTPxLH18dZnwLK3qEU0XCq742dAfhMSsf29SuW ng3uIibBVryGeX11OHRpAxpenjQFrZEp9/cFOF+kK1Vap6Z5JxA+RFVaxzgbMzc5ox1X t+sQSTzVBHN3+aYxKSq/1B1Rhx7xF/mciUWS1mnyttS4/3ZNOkcFLgonUEzZaO660HnK Dwgal/ujHkPDLMIuM+tL+V5yy6hffhgx+A0sicwvVTKREy5VSBUH9o4hbIz57GaLWrip /pGA==
MIME-Version: 1.0
X-Received: by 10.113.5.7 with SMTP id ci7mr16982854lbd.9.1413432518054; Wed, 15 Oct 2014 21:08:38 -0700 (PDT)
Received: by 10.25.143.203 with HTTP; Wed, 15 Oct 2014 21:08:37 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>        
Date: Thu, 16 Oct 2014 10:08:37 +0600
Message-ID: 
From: Fahima Ahmed Khan Etha 
To: TLS@ietf.org
Content-Type: multipart/alternative; boundary=001a1133a890271ad005058267e3
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pl5KCKxrKihTSYn0FIhc-fdH33M
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 04:08:45 -0000

--001a1133a890271ad005058267e3
Content-Type: text/plain; charset=UTF-8

Dear All,

It might be an off topic. But I am seeking guidance from all of you.

If any hacker group claimed that you are hacked... How to proof or find out
its authenticity?

Please share your view.

Best regards,

Fahima

On 3 October 2014 23:09, Brian Smith  wrote:

> On Fri, Sep 26, 2014 at 11:58 AM, Brian Smith 
> wrote:
> > On Fri, Sep 26, 2014 at 12:34 AM, Bodo Moeller  wrote:
> >>> I'm OK with that, but if this is the real reason for the MUST, then
> >>> it's not particularly clear.
> >>
> >> Hm, maybe so. I can add a brief note showing how the handshake would
> fail if
> >> the server acts on the SCSV in this case, but I don't think the document
> >> should have to explain why we require the client to omit the SCSV rather
> >> than having the server ignore it. (Why would you want to send it if
> nothing
> >> follows from that?)
> >
> > Here is what the draft actually says:
> >
> >       However, as an exception to the above, when the client intends to
> >       perform an abbreviated handshake to resume a previously negotiated
> >       session and sets ClientHello.client_version to the protocol
> >       version negotiated for that session, the client MUST NOT include
> >       TLS_FALLBACK_SCSV in ClientHello.cipher_suites.
> >
> > So, if the client does NOT set ClientHello.client_version to the
> > version negotiated for that session, then the client MAY send the SCSV
> > in the resumption handshake.
>
> Bodo, could you please reword the above to make it clearer? e.g.:
>
> "However, as an exception to the above, when the client sets
> ClientHello.client_version to the protocol version negotiated for for
> a session that it is trying to resume, and that version is less than
> the ClientHello.client_version it would otherwise send if it were not
> attempting to resume a session, then the client MUST NOT include
> TLS_FALLBACK_SCSV in ClientHello.cipher_suites.
>
> For example, if the client is doing a non-secure fallback, and it is
> resuming a session that previously negotiated TLS 1.0, and it sets
> ClientHello.client_version to TLS 1.1, then TLS_FALLBACK_SCSV must be
> included in ClientHello.cipher_suites. However, as another example, if
> the client is resuming a session that previously negotiated TLS 1.0,
> and it sets ClientHello.client_version to TLS 1.0 to match the version
> number of the session, then it must not include TLS_FALLBACK_SCSV in
> ClientHello.cipher_suites."
>
> > Now, if the server could indicate that it supports the SCSV somehow in
> > its ServerHello, then the client could save that acknowledgement in
>
> Please ignore this suggestion I had about an explicit indicator. It
> isn't important and there are better ways of accomplishing the same
> effect.
>
> Cheers,
> Brian
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a1133a890271ad005058267e3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





Dear All,



It might be an off topic. But I am seeking guidance from all
of you.



If any hacker group claimed that you are hacked... How to
proof or find out its authenticity?



Please share your view.



=
Best regards,



Fahima




On 3 Octobe=
r 2014 23:09, Brian Smith <brian@briansmith.org> wrote:
On Fri, Sep 26, 2014 at 11:58 AM, Brian Sm=
ith <brian@briansmith.org>=
; wrote:

> On Fri, Sep 26, 2014 at 12:34 AM, Bodo Moeller <bmoeller@acm.org> wrote:

>>> I'm OK with that, but if this is the real reason for the M=
UST, then

>>> it's not particularly clear.

>>

>> Hm, maybe so. I can add a brief note showing how the handshake wou=
ld fail if

>> the server acts on the SCSV in this case, but I don't think th=
e document

>> should have to explain why we require the client to omit the SCSV =
rather

>> than having the server ignore it. (Why would you want to send it i=
f nothing

>> follows from that?)

>

> Here is what the draft actually says:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0However, as an exception to the above, when =
the client intends to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0perform an abbreviated handshake to resume a=
 previously negotiated

>=C2=A0 =C2=A0 =C2=A0 =C2=A0session and sets ClientHello.client_version =
to the protocol

>=C2=A0 =C2=A0 =C2=A0 =C2=A0version negotiated for that session, the cli=
ent MUST NOT include

>=C2=A0 =C2=A0 =C2=A0 =C2=A0TLS_FALLBACK_SCSV in ClientHello.cipher_suit=
es.

>

> So, if the client does NOT set ClientHello.client_version to the

> version negotiated for that session, then the client MAY send the SCSV=


> in the resumption handshake.



Bodo, could you please reword the above to make it clearer? e.g.:



"However, as an exception to the above, when the client sets

ClientHello.client_version to the protocol version negotiated for for

a session that it is trying to resume, and that version is less than

the ClientHello.client_version it would otherwise send if it were not

attempting to resume a session, then the client MUST NOT include

TLS_FALLBACK_SCSV in ClientHello.cipher_suites.



For example, if the client is doing a non-secure fallback, and it is

resuming a session that previously negotiated TLS 1.0, and it sets

ClientHello.client_version to TLS 1.1, then TLS_FALLBACK_SCSV must be

included in ClientHello.cipher_suites. However, as another example, if

the client is resuming a session that previously negotiated TLS 1.0,

and it sets ClientHello.client_version to TLS 1.0 to match the version

number of the session, then it must not include TLS_FALLBACK_SCSV in

ClientHello.cipher_suites."



> Now, if the server could indicate that it supports the SCSV somehow in=


> its ServerHello, then the client could save that acknowledgement in


Please ignore this suggestion I had about an explicit indicator. It

isn't important and there are better ways of accomplishing the same

effect.



Cheers,

Brian



_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--001a1133a890271ad005058267e3--


From nobody Thu Oct 16 02:03:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B7E1A1AE0 for ; Thu, 16 Oct 2014 02:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qacLbrvlEPD for ; Thu, 16 Oct 2014 02:03:06 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960721A1AB6 for ; Thu, 16 Oct 2014 02:03:06 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9G932lW030155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Oct 2014 05:03:02 -0400
Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9G930bU029449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 05:03:02 -0400
Message-ID: <543F89C4.3020303@redhat.com>
Date: Thu, 16 Oct 2014 11:03:00 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Bodo Moeller 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>	<543E95AE.1030300@redhat.com> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/h1v5_djnc0rVAuVS5myxWAEXLWQ
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 09:03:08 -0000

On 10/15/2014 08:09 PM, Bodo Moeller wrote:
> "Florian Weimer" >:
>
>  > One more issue: The draft is silent on how to respond to an
> inappropriate_fallback alert.
>
> No, it is expressly a fatal alert. What else do you think would need to
> be said?

If it were that clear, we wouldn't need this new SCSV at all because 
browsers would never have performed fallback in response to fatal alerts.

So far I've come up with the following questions:

Should the client continue to retry with lower TLS versions once it 
receives an inappropriate_fallback alert?

Should it retry without the SCSV?  I guess you mean "no way!", but this 
is only implicit.

-- 
Florian Weimer / Red Hat Product Security


From nobody Thu Oct 16 03:06:23 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA1F1ACEFF for ; Thu, 16 Oct 2014 03:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udfAmgRukobx for ; Thu, 16 Oct 2014 03:06:18 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2071ACEFE for ; Thu, 16 Oct 2014 03:06:18 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9GA6EN4018008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Oct 2014 06:06:14 -0400
Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9GA6Cpa030395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 06:06:13 -0400
Message-ID: <543F9893.806@redhat.com>
Date: Thu, 16 Oct 2014 12:06:11 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Martin Thomson , Bodo Moeller 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2g315qVhEgMhlsPdxMcLli7PXtk
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 10:06:21 -0000

On 10/15/2014 08:24 PM, Martin Thomson wrote:
> On 15 October 2014 11:09, Bodo Moeller  wrote:
>> Preventing such attacks, of course, is what we consider a feature. Google
>> servers support the SCSV, and so does the Chrome browser; so we have the
>> required real-life experience indicating that deploying the SCSV is
>> practical.
>
> And I'd like to add that the SCSV has been in Firefox Nightly for a
> while now.  We got some early reports of problems because of the way
> we were reacting to spurious fallbacks, but that has been addressed
> and I've not seen any subsequent reports of problems.

Interesting things will start to happen once there is TLS 1.3. 
TLS_FALLBACK_SCSV could really complicate its deployment.

> This is a strictly good feature for Firefox users.  The alternative
> (disable insecure version intolerant fallback entirely) is completely
> untenable for us.

Why do you think that?  Is this observation based on data tainted by the 
spurious downgrade bugs you had?  Do you know if the downgrades are due 
to server problems or interception by law enforcement?  (I suspect the 
latter would magically go away if you got rid of the fallback code.)

I just find it difficult to reconcile your decision to keep the fallback 
with the announcement to disable SSL 3.0 by default.  Surely the latter 
change is going to bite many users.  (I'm aware that fallback can still 
happen from one TLS version to another, that's not what puzzles me.)

-- 
Florian Weimer / Red Hat Product Security


From nobody Thu Oct 16 03:26:55 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9461ACF70 for ; Thu, 16 Oct 2014 03:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level: 
X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVjoCnN2qphc for ; Thu, 16 Oct 2014 03:26:53 -0700 (PDT)
Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD541ACF6D for ; Thu, 16 Oct 2014 03:26:53 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9GAQnxh018340; Thu, 16 Oct 2014 06:26:49 -0400
Date: Thu, 16 Oct 2014 06:26:48 -0400 (EDT)
From: Hubert Kario 
To: Hanno =?utf-8?B?QsO2Y2s=?= 
Message-ID: <257636459.12399546.1413455208860.JavaMail.zimbra@redhat.com>
In-Reply-To: <20141015140158.41a1faf8@pc.my-domain>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <20141015140158.41a1faf8@pc.my-domain>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.5.82.7]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922)
Thread-Topic: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: 9+dKQv7djuLB7N2jDqdxcqQ3t0Ms7A==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IEmfwT3u_Dei1IX4JhDap6degFI
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 10:26:54 -0000

----- Original Message -----
> From: "Hanno B=C3=B6ck" 
> To: tls@ietf.org
> Sent: Wednesday, 15 October, 2014 2:01:58 PM
> Subject: Re: [TLS] Working Group Last Call for=09draft-ietf-tls-downgrade=
-scsv-00
>=20
> Am Wed, 15 Oct 2014 11:22:51 +0200
> schrieb Bodo Moeller :
>=20
> > Note that if your server does not support formally obsolete protocol
> > versions, TLS_FALLBACK_SCSV support is a no-op.
> >=20
> > Otherwise, you're making real-world tradeoffs, and I think
> > TLS_FALLBACK_SCSV is a reasonable one to make (with minimal
> > server-side logic to achieve the objective), not "punishment".
>=20
> Can you quantify that tradeoff? How many devices are there really out
> there that would break? I'd like to have this discussions with
> hard numbers.

I don't have hard numbers for that (I'm +1 this request), but
looking forward, I see many servers that are TLS 1.3 intolerant while
randomly scanning servers using the ssllabs.com scanner.

So it's not only about servers that are TLS1.2 Client Hello intolerant
(they should be mostly eradicated from the public Internet by now)
but also possible future issues.

--=20
Regards,
Hubert Kario


From nobody Thu Oct 16 03:36:14 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B621ACFC7 for ; Thu, 16 Oct 2014 03:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.31
X-Spam-Level: 
X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_BACK=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_TNiDatkoOF for ; Thu, 16 Oct 2014 03:36:12 -0700 (PDT)
Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8FB1ACFBC for ; Thu, 16 Oct 2014 03:36:11 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9GAa7TL019639; Thu, 16 Oct 2014 06:36:07 -0400
Date: Thu, 16 Oct 2014 06:36:07 -0400 (EDT)
From: Hubert Kario 
To: Bodo Moeller 
Message-ID: <95496672.12403991.1413455767572.JavaMail.zimbra@redhat.com>
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <20141015140158.41a1faf8@pc.my-domain> 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_12403990_1800712949.1413455767571"
X-Originating-IP: [10.5.82.7]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922)
Thread-Topic: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Zd0q0bIR1BxgFHXKbxGYvuWHoEsJ+A==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wrykeXglVsPt1-k8XnzsHON6FT4
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 10:36:13 -0000

------=_Part_12403990_1800712949.1413455767571
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

----- Original Message -----

> From: "Bodo Moeller" 
> To: tls@ietf.org
> Sent: Wednesday, 15 October, 2014 2:59:59 PM
> Subject: Re: [TLS] Working Group Last Call for
> draft-ietf-tls-downgrade-scsv-00

> Hanno B=C3=B6ck < hanno@hboeck.de > :

> > Can you quantify that tradeoff? How many devices are there really out
>=20
> > there that would break? I'd like to have this discussions with
>=20
> > hard numbers.
>=20

> Finding hard numbers is, well, hard. In general, you find out the whole
> picture about what you've broken only after you've broken it.

> That doesn't mean that people aren't trying to get good estimates (Ivan
> Ristic has done some data collection -- I've include some of his results =
in
> slide 2 of http://www.ietf.org/proceedings/90/slides/slides-90-tls-0.pdf =
)

nice=20
so ~1% is intolerant to TLS1.1=20
~1% is intolerant to 1.2=20
and 11% is intolerant to 1.3 (!!)=20

were there any servers intolerant to TLS1.0?=20

--=20
Regards,=20
Hubert Kario=20

------=_Part_12403990_1800712949.1413455767571
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable




Fr=
om: "Bodo Moeller" <bmoeller@acm.org>
To: tls@ietf.org<=
br>Sent: Wednesday, 15 October, 2014 2:59:59 PM
Subject: R=
e: [TLS] Working Group Last Call for      &nb=
sp; draft-ietf-tls-downgrade-scsv-00

Hanno B=C3=B6ck <han=
no@hboeck.de>:

Can you quantify that tradeoff? How many devices are there really ou=
t

there that would break? I'd like to have this discussions with

hard numbers.

Finding hard numbers is, =
well, hard. In general, you find out the whole picture about what you've br=
oken only after you've broken it.

That doesn't mea=
n that people aren't trying to get good estimates (Ivan Ristic has done som=
e data collection -- I've include some of his results in slide 2 of http://www.ietf.org/proceedings/90/slides/slides-90-tls-0.pdf)


were there any servers intolerant to TLS1.0?


------=_Part_12403990_1800712949.1413455767571--


From nobody Thu Oct 16 03:40:41 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345611ACFE5 for ; Thu, 16 Oct 2014 03:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gdXydw1DeWb for ; Thu, 16 Oct 2014 03:40:38 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44DB1ACFEF for ; Thu, 16 Oct 2014 03:40:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=0DovcG9aH+ZcDV4OZY4pE+xJJMG8TwbsFXI0N8JJnJw=;  b=aTUlqKw95SZi98w0K0UfYk2nSNnWkGnHt2faj2Th68E3/kFedziFicSTHbqLrld7QA+hQxWNfeaPTE5i+61ZUn0yI43ZJZbUOB1FpCpx2Z6cR6t1SpFNmqOZMgSmKMIoF7lELxUNcCENDi11MolmHvqEBx0LuwB4kE3eWWhzsmw=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XeiTu-00026c-KM; Thu, 16 Oct 2014 12:40:30 +0200
Message-ID: <543FA0A0.1030205@polarssl.org>
Date: Thu, 16 Oct 2014 12:40:32 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Florian Weimer ,  Martin Thomson , Bodo Moeller 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com>
In-Reply-To: <543F9893.806@redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2PJ60jVKrTl46yrTWm0Po7Iyy-k
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 10:40:39 -0000

On 16/10/2014 12:06, Florian Weimer wrote:
> Interesting things will start to happen once there is TLS 1.3. 
> TLS_FALLBACK_SCSV could really complicate its deployment.
> 
I'm afraid I don't understand which interesting things you're referring to.
Could you please elaborate on that?

I can think of the following scenarios (assuming the client supports 1.3 and
FALLBACK_SCSV):

1. The server also supports 1.3, and no middleware is blocking it -> all good.

2. The server also supports 1.3, but some middleware/attacker is blocking it.
The client retries with 1.2+FALLBACK_SCSV.
	2a. The server also supports FALLBACK_SCSV. The MitM downgrade is avoided.
That's a feature.
	2b. The server doesn't support FALLBACK_SCSV. The MitM downgrade succeeds. Too bad.

3. The server doesn't support 1.3 but is version-tolerant (and so is all
middleware in path). 1.2 is negotiated using the intended mechanism -> all good.

4. The server doesn't support 1.3 but it (or some middleware/attacker) is
1.3-version intolerant. The client retries with 1.2+FALLBACK_SCSV. Regardless of
whether the server supports FALLBACK_SCSV, the handshake succeeds because 1.2 is
indeed the highest version supported by the server. (Assuming it's 1.2 for the
sake of simplicity, but it should work the same way for lower versions.)

What am I missing?

Manuel.


From nobody Thu Oct 16 06:41:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950971A008C for ; Thu, 16 Oct 2014 06:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.611
X-Spam-Level: 
X-Spam-Status: No, score=-6.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUAMXlFbY-0U for ; Thu, 16 Oct 2014 06:41:08 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6269F1A0010 for ; Thu, 16 Oct 2014 06:41:08 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9GDf354009608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Oct 2014 09:41:04 -0400
Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9GDf1ku005807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 09:41:02 -0400
Message-ID: <543FCAED.50502@redhat.com>
Date: Thu, 16 Oct 2014 15:41:01 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= , Martin Thomson , Bodo Moeller 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org>
In-Reply-To: <543FA0A0.1030205@polarssl.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/t7OZLFd0oXjdE2gIENEVmg1j5Cc
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:41:14 -0000

On 10/16/2014 12:40 PM, Manuel Pégourié-Gonnard wrote:
> On 16/10/2014 12:06, Florian Weimer wrote:
>> Interesting things will start to happen once there is TLS 1.3.
>> TLS_FALLBACK_SCSV could really complicate its deployment.
>>
> I'm afraid I don't understand which interesting things you're referring to.
> Could you please elaborate on that?
>
> I can think of the following scenarios (assuming the client supports 1.3 and
> FALLBACK_SCSV):

A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV 
unconditionally.  This client would break once servers start supporting 
TLS 1.3.  That's just one example of what could go wrong which could not 
go wrong before.

-- 
Florian Weimer / Red Hat Product Security


From nobody Thu Oct 16 06:44:48 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF891A0110 for ; Thu, 16 Oct 2014 06:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level: 
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tyke3huFgCi6 for ; Thu, 16 Oct 2014 06:44:45 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 735D01A00F1 for ; Thu, 16 Oct 2014 06:44:45 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CC91D47616; Thu, 16 Oct 2014 13:44:44 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C080F47612; Thu, 16 Oct 2014 13:44:44 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id BCF0C202C; Thu, 16 Oct 2014 13:44:44 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 16 Oct 2014 09:44:39 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Thu, 16 Oct 2014 09:44:39 -0400
From: "Salz, Rich" 
To: Florian Weimer , =?iso-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , "Martin Thomson" , Bodo Moeller 
Date: Thu, 16 Oct 2014 09:44:37 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/pRt+58jqfaEX6Ri27GOg97QhfcwAAC/eQ
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com>
In-Reply-To: <543FCAED.50502@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nDrlhOr7EPZew_gUWto6X-q7fQg
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:44:46 -0000

> A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV
> unconditionally.

A widely deployed client might also start injecting line noise into the TLS=
 stream.

We can't control what buggy clients do.  That's not new.


=20


From nobody Thu Oct 16 06:48:12 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041C31A0123 for ; Thu, 16 Oct 2014 06:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vuQrm__cc8f for ; Thu, 16 Oct 2014 06:48:07 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97EB61A038E for ; Thu, 16 Oct 2014 06:48:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=wmLXmCEUtKWSzlHWkQFugShGmnYcqFAKZ0gWmWpaZ5Q=;  b=bkmYm7/MM5q5OwNEvNugSw5YSPp7kkxDIudqMM0DOv+f4Kc5TLRoTq9NJ4/bjFaToOLtYQ/HeThpsRO6yJObp48Kmu1rg6YPYLxepn7HX1SUTVCwV+RDnnkrQFkd9mBGMUdFfN6clO9dnvcNP9yXL0pFcnlXW3hUl15LYnLjBdg=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XelPJ-0002Jg-5U; Thu, 16 Oct 2014 15:47:57 +0200
Message-ID: <543FCC90.7020408@polarssl.org>
Date: Thu, 16 Oct 2014 15:48:00 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Florian Weimer ,  Martin Thomson , Bodo Moeller 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com>
In-Reply-To: <543FCAED.50502@redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9pGXsgs61ADuFnLBenRX_ZBBFBQ
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:48:09 -0000

On 16/10/2014 15:41, Florian Weimer wrote:
> On 10/16/2014 12:40 PM, Manuel Pégourié-Gonnard wrote:
>> On 16/10/2014 12:06, Florian Weimer wrote:
>>> Interesting things will start to happen once there is TLS 1.3.
>>> TLS_FALLBACK_SCSV could really complicate its deployment.
>>>
>> I'm afraid I don't understand which interesting things you're referring to.
>> Could you please elaborate on that?
>>
> A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV 
> unconditionally.  This client would break once servers start supporting 
> TLS 1.3.  That's just one example of what could go wrong which could not 
> go wrong before.
> 
I'm sorry, but wouldn't that be very stupid of the client? Maybe the draft could
include wording that clients MUST NOT do that, to be extra clear, but IMHO it's
already quite clear.

Besides clients doing this stupid thing, do you see other bad things related to
FALLBACK_SCSV that could happen when TLS 1.3 will start being deployed?

Manuel.


From SRS0=Aa5u=7H=acm.org=bmoeller@srs.kundenserver.de  Thu Oct 16 06:54:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284EF1A1A18 for ; Thu, 16 Oct 2014 06:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS9EGgcf4REO for ; Thu, 16 Oct 2014 06:54:16 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83F81A19E9 for ; Thu, 16 Oct 2014 06:54:15 -0700 (PDT)
Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0MeBeI-1Xo33r285O-00PwRt; Thu, 16 Oct 2014 15:54:13 +0200
Received: by mail-yh0-f44.google.com with SMTP id i57so1955541yha.31 for ; Thu, 16 Oct 2014 06:54:11 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.22.228 with SMTP id t64mr1922847yht.164.1413467651399; Thu, 16 Oct 2014 06:54:11 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Thu, 16 Oct 2014 06:54:11 -0700 (PDT)
In-Reply-To: <543F89C4.3020303@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E95AE.1030300@redhat.com>  <543F89C4.3020303@redhat.com>
Date: Thu, 16 Oct 2014 15:54:11 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=e89a8f642a98436a1c05058a95b1
X-Provags-ID: V02:K0:gNwQ0N7dGDvEu5IHtf2xXxDSryWlO411VMBNkhSeSf3 taj1MylYVUDFGZ09jYBCoZiKc4EqNyryJRiQaYxznT7bJL19Fx R1dAvd3knnsal8quj44k4K44ym+tO2rW6V7gZACdZ2SEsAzhS0 rHnRSnw+B4bfi97+TTZfEDYW3CYDcYflr/r2zf4NKc4lH0SaJY 5sM8ICKHIjvXBah5aQKXlWnRLVyl/zfNHOTGykpa6g5RyEjNHc HxbCCbRG+x75mtU/ZsXfyVynA3coud7hiuNILKrmdkYbBBsmNK mHZ7AnVDbVBt8mDByUvrfRkokAq74w/cjSth7kCns6liPNY/lF Appt2u0YY5BgHAGQBzzO5nzjM9ccJeSQ2AC8/+JWr6W2CjmMRS 7jx+0+1vKFYTYyoBtQBclmu5AG/oLfEzwBqaC8Ms4CwYjz3yZn KMWfe
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eoG8eswopYlwm18bLpIwWBHme_Y
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:54:51 -0000

--e89a8f642a98436a1c05058a95b1
Content-Type: text/plain; charset=UTF-8

Florian Weimer :

 > One more issue: The draft is silent on how to respond to
>> an inappropriate_fallback alert.
>>
>

> No, it is expressly a fatal alert. What else do you think would need to
>> be said?
>>
>

> So far I've come up with the following questions:
>

> Should the client continue to retry with lower TLS versions once it
> receives an inappropriate_fallback alert?
>
> Should it retry without the SCSV?  I guess you mean "no way!", but this is
> only implicit.


I see. The current I-D indeed doesn't say that you can't continue to retry
with lower versions in response to inappropriate_fallback, but I see no
need for normative language on that (it seems stupid, but not harmful). It
still can't hurt to mention that point, I guess.

Retry without SCSV in response to inappropriate_fallback? Here the same
SHOULD NOT applies as for the previous attempt, and I fail to see why
anyone would decide that doing the additional retry without SCSV could be
acceptable if they understand the full implications and carefully weigh the
case, so again I see no need to change the normative language. But then if
you honestly believe that the current language invites misguided
implementors to retry without SCSV, I wouldn't be opposed to adding an
explicit MUST NOT for that case.

Bodo

--e89a8f642a98436a1c05058a95b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Flor=
ian Weimer <fweimer@redhat.com>:


=C2=A0> One more issue: The draft is silent on how to respond to an=C2=
=A0inappropriate_fallback alert.
<=
div>=C2=A0

No, it is expressly a fatal alert. What else do you think would need to

be said?
=C2=A0
So far I've come up with the following questions:
=




Should the client continue to retry with lower TLS versions once it receive=
s an inappropriate_fallback alert?



Should it retry without the SCSV?=C2=A0 I guess you mean "no way!"=
;, but this is only implicit.

I see. The cu=
rrent I-D indeed doesn't say that you can't continue to retry with =
lower versions in response to inappropriate_fallback, but I see no need for=
 normative language on that (it seems stupid, but not harmful). It still ca=
n't hurt to mention that point, I guess.

Retry=
 without SCSV in response to inappropriate_fallback? Here the same SHOULD N=
OT applies as for the previous attempt, and I fail to see why anyone would =
decide that doing the additional retry without SCSV could be acceptable if =
they understand the full implications and carefully weigh the case, so agai=
n I see no need to change the normative language. But then if you honestly =
believe that the current language invites misguided implementors to retry w=
ithout SCSV, I wouldn't be opposed to adding an explicit MUST NOT for t=
hat case.

Bodo



--e89a8f642a98436a1c05058a95b1--


From nobody Thu Oct 16 06:57:09 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8671A19FE for ; Thu, 16 Oct 2014 06:57:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqH_cTsZqgCZ for ; Thu, 16 Oct 2014 06:57:05 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 05AA81A19F9 for ; Thu, 16 Oct 2014 06:57:04 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9B4B2475FD; Thu, 16 Oct 2014 13:57:04 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 8ED784757A; Thu, 16 Oct 2014 13:57:04 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 8B8C080044; Thu, 16 Oct 2014 13:57:04 +0000 (GMT)
Received: from usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 16 Oct 2014 09:57:03 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Thu, 16 Oct 2014 09:57:03 -0400
From: "Salz, Rich" 
To: Florian Weimer , Bodo Moeller 
Date: Thu, 16 Oct 2014 09:57:02 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/pICKwR28ouSaTTz6hAqPpRAsL2QAKHRLg
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECC3@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E95AE.1030300@redhat.com>  <543F89C4.3020303@redhat.com>
In-Reply-To: <543F89C4.3020303@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JC5WUC2k6FjMt9wE2H690FvozbI
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:57:06 -0000

> Should the client continue to retry with lower TLS versions once it recei=
ves an
> inappropriate_fallback alert?

Sure, if it likes  being told no over and over again. :)

> Should it retry without the SCSV?  I guess you mean "no way!", but this i=
s
> only implicit.

I disagree with Bodo.  It's a user-agent issue. A browser might pop up a wa=
rning about the loss of privacy features and ask if it should proceed.

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz



From SRS0=Aa5u=7H=acm.org=bmoeller@srs.kundenserver.de  Thu Oct 16 06:36:59 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC891A037A for ; Thu, 16 Oct 2014 06:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZPpG3IZr5SN for ; Thu, 16 Oct 2014 06:36:57 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DADD81A1BC5 for ; Thu, 16 Oct 2014 06:36:56 -0700 (PDT)
Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0LwIKE-1YELoB48b8-0187Qk; Thu, 16 Oct 2014 15:36:54 +0200
Received: by mail-yh0-f47.google.com with SMTP id c41so1923616yho.20 for ; Thu, 16 Oct 2014 06:36:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.203.114 with SMTP id e78mr1731446yho.47.1413466612684; Thu, 16 Oct 2014 06:36:52 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Thu, 16 Oct 2014 06:36:52 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> 
Date: Thu, 16 Oct 2014 15:36:52 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0158c7c459df3805058a57c1
X-Provags-ID: V02:K0:kwC4elwWREo4BNCqdCjQTVOHLWIaSC/lgBi6P7uP+E2 /XiEdmgQbzig5dsNdtlIO3r//jnxQe3TdZmfgbst/4ymT+M5MP dL5Dv9fvLltPTRzbhAus2jpaPva5wH0mvJE4z0PWtwf0iT/0mJ r2PdsbzeieLUL1O7FeQ5QCfY62gHVCsb+jFq7QVuT2oRlZWye5 sUubP84+yQmWAaERY8myPWB2j6CFKvIBwqfLZF9sse8t5EDVgT ft9HBrUFrTCv4OPed8k9DtBrWGnqhxrwROMynAB4payODo3JZ0 mERTSXnMwudAgnpLVnJQld2tvRjIut76fJieadwYhoR5cTIIE9 kckIjrHutY6m6/aacEFTXcWEnwy681p6seTuiQ82WTYO8ChCNF EGc9zjxiUM2EkZ6RMd9/QgHOFWejHSM4Yjma6MNDm6oz8KxrA4 J4ANb
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9vo8TEbdb_0QG_nlS9gjvIbAJAI
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:02:52 -0000

--089e0158c7c459df3805058a57c1
Content-Type: text/plain; charset=UTF-8

Brian Smith :

It seems like the draft should also advise clients that they MUST NOT
> do the False Start optimization if the server does not choose the
> maximum version of TLS that they support. For example, if the server
> chooses a version less than ClientHello.client_version, or if the
> client sent the TLS_FALLBACK_SCSV, then the client MUST NOT false
> start. Currently the draft says nothing about this. Because of False
> Start, there are several downgrades that are still possible even with
> the current downgrade-SCSV-enabled Chrome and Firefox, for example.
>

This is a valid concern about the interaction of allowing fallback protocol
versions (whether using the normal version negotiation mechanism, or
fallback retries) with False Start. Obviously the False Start spec already
covers such aspects on a general level (do not use False Start unless the
symmetric cipher is cryptographically strong, etc.), but points such as the
one that older protocol versions may have *no* sufficiently secure cipher
suites at all are not made explicit.

This isn't specific to fallback retries and certainly not to the
TLS_FALLBACK_SCSV mechanism (it's exactly the same with the standard
mechanism for protocol version negotiation), so I think an updated version
of the False Start specification would be the right place to set any strict
requirements for this. However, it would make sense to *mention* and
discuss this aspect in the TLS_FALLBACK_SCSV document (non-normatively).


[As for the specifics, while I think this isn't really for the
TLS_FALLBACK_SCSV specification to define, allowing False Start only with
the *one* most recent protocol version appears too strict. Specifically,
while deployment of a new protocol version is underway, clients may want to
use False Start both with this new version and with the previous version --
why downgrade the overall experience for those who enable the latest
protocol version?]



> In summary, the way it is defined, the downgrade SCSV is only helpful
> in preventing a limit number of unspecified downgrade attacks when
> used in conjunction with False Start. Also, the draft is based on the
> premise that preventing version downgrade is useful for preventing
> some cryptographic attacks, but it does not substantiate that. POODLE
> and BEAST are evidence that the mechanism helps for some attacks. But,
> is this mechanism actually effective for preventing any other class of
> attacks, other than TLS 1.1 -> TLS 1.0 -> SSL 3.0 downgrade for CBC
> cipher suites? The answer to this should be in the security
> considerations.
>

Well, what makes the TLS_FALLBACK_SCSV mechanism particularly valuable is
that it can help protect you from attacks that no one is aware of yet. So
enumerating concrete attacks sort of would be missing the point:
TLS_FALLBACK_SCSV is mainly about those vulnerabilities that we *can't*
list there yet. I can tell you *now* how you would have benefited from
supporting TLS_FALLBACK_SCSV half a year ago.

The simplest argument in favor of preventing unwarranted fallback to
earlier protocol versions is that if we didn't think that the newer
versions were better, why would we be specifying them in the first place?

That said, the question whether the mechanism has relevance for weaknesses
other than those found in CBC cipher suites can be answered in the
affirmative. For example, if clients fall back to SSL 3.0 without TLS
extensions, they can't use ECDHE and thus may lose forward security.

Bodo

--089e0158c7c459df3805058a57c1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Bria=
n Smith <brian@briansmith.org>:

It seems like the draft should also advise clie=
nts that they MUST NOT

do the False Start optimization if the server does not choose the

maximum version of TLS that they support. For example, if the server

chooses a version less than ClientHello.client_version, or if the

client sent the TLS_FALLBACK_SCSV, then the client MUST NOT false

start. Currently the draft says nothing about this. Because of False

Start, there are several downgrades that are still possible even with

the current downgrade-SCSV-enabled Chrome and Firefox, for example.

This is a valid concern about the interaction =
of allowing fallback protocol versions (whether using the normal version ne=
gotiation mechanism, or fallback retries) with False Start. Obviously the F=
alse Start spec already covers such aspects on a general level (do not use =
False Start unless the symmetric cipher is cryptographically strong, etc.),=
 but points such as the one that older protocol versions may have *no* suff=
iciently secure cipher suites at all are not made explicit.

<=
/div>
This isn't specific to fallback retries and certainly not to =
the TLS_FALLBACK_SCSV mechanism (it's exactly the same with the standar=
d mechanism for protocol version negotiation), so I think an updated versio=
n of the False Start specification would be the right place to set any stri=
ct requirements for this. However, it would make sense to *mention* and dis=
cuss this aspect in the TLS_FALLBACK_SCSV document (non-normatively).
=



[As for the specifics, while I think thi=
s isn't really for the TLS_FALLBACK_SCSV specification to define, allow=
ing False Start only with the *one* most recent protocol version appears to=
o strict. Specifically, while deployment of a new protocol version is under=
way, clients may want to use False Start both with this new version and wit=
h the previous version -- why downgrade the overall experience for those wh=
o enable the latest protocol version?]

=C2=A0

In summary, the way it is defined, the downgrade SCSV is only helpful

in preventing a limit number of unspecified downgrade attacks when

used in conjunction with False Start. Also, the draft is based on the

premise that preventing version downgrade is useful for preventing

some cryptographic attacks, but it does not substantiate that. POODLE

and BEAST are evidence that the mechanism helps for some attacks. But,

is this mechanism actually effective for preventing any other class of

attacks, other than TLS 1.1 -> TLS 1.0 -> SSL 3.0 downgrade for CBC
cipher suites? The answer to this should be in the security

considerations.

Well, what makes the TL=
S_FALLBACK_SCSV mechanism particularly valuable is that it can help protect=
 you from attacks that no one is aware of yet. So enumerating concrete atta=
cks sort of would be missing the point: TLS_FALLBACK_SCSV is mainly about t=
hose vulnerabilities that we *can't* list there yet. I can tell you *no=
w* how you would have benefited from supporting TLS_FALLBACK_SCSV half a ye=
ar ago.

The simplest argument in favor of preventi=
ng unwarranted fallback to earlier protocol versions is that if we didn'=
;t think that the newer versions were better, why would we be specifying th=
em in the first place?

That said, the question whe=
ther the mechanism has relevance for weaknesses other than those found in C=
BC cipher suites can be answered in the affirmative. For example, if client=
s fall back to SSL 3.0 without TLS extensions, they can't use ECDHE and=
 thus may lose forward security.

Bodo



--089e0158c7c459df3805058a57c1--


From nobody Thu Oct 16 07:04:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A751A1A25 for ; Thu, 16 Oct 2014 07:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.612
X-Spam-Level: 
X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnHTFY0KiYMd for ; Thu, 16 Oct 2014 07:04:13 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF3F1A1A24 for ; Thu, 16 Oct 2014 07:04:13 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9GE4BEq029743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Oct 2014 10:04:12 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9GE48eZ006989 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2014 10:04:10 -0400
Message-ID: <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Manuel =?ISO-8859-1?Q?P=E9gouri=E9-Gonnard?= 
Date: Thu, 16 Oct 2014 16:04:07 +0200
In-Reply-To: <543FCC90.7020408@polarssl.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zNMThGs4YcXh96NlRxX7rf5Mpic
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:04:15 -0000

On Thu, 2014-10-16 at 15:48 +0200, Manuel Pégourié-Gonnard wrote:

> > A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV 
> > unconditionally.  This client would break once servers start supporting 
> > TLS 1.3.  That's just one example of what could go wrong which could not 
> > go wrong before.
> > 
> I'm sorry, but wouldn't that be very stupid of the client? Maybe the draft could
> include wording that clients MUST NOT do that, to be extra clear, but IMHO it's
> already quite clear.

Of course, but isn't this issue that SCSV is trying to fix in the first
place? Isn't the SCSV's reason of existance the fact that there are some
buggy servers that cannot handle TLS protocol version negotiation? Why
should we assume that buggy clients are impossible to happen?

regards,
Nikos



From nobody Thu Oct 16 07:06:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046801A1A6C for ; Thu, 16 Oct 2014 07:06:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level: 
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fvv7B2fVhpBZ for ; Thu, 16 Oct 2014 07:06:36 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE5C1A1A67 for ; Thu, 16 Oct 2014 07:06:36 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 81B56285A5; Thu, 16 Oct 2014 14:06:35 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 6C0C928521; Thu, 16 Oct 2014 14:06:35 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 670FC2027; Thu, 16 Oct 2014 14:06:35 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 16 Oct 2014 10:06:34 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Thu, 16 Oct 2014 10:06:34 -0400
From: "Salz, Rich" 
To: Nikos Mavrogiannopoulos , =?utf-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= 
Date: Thu, 16 Oct 2014 10:06:31 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/pShVOWFjod1f+R/2+NHYy4hz1bgAACFAQ
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECD5@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7SN-7-SE9FzTJ4YXRTW4a-JVzHs
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:06:39 -0000

QnVnZ3kgc2VydmVycyBjYXVzZWQgYnVnZ3kgY2xpZW50cyB3aGljaCBub3cgY2F1c2VkIHNpbGVu
dCBsb3NzIG9mIHNlY3VyaXR5IHByb3BlcnRpZXMuICBTQ1NWIGZhbGxiYWNrIGlzIGFuIGVmZmVj
dGl2ZSB3YXkgdG8gaGVscCBicmVhayB0aGUgY3ljbGUuDQoNCihBbmQgd2hhdCBhcmUgeW91IFJI
IGZvbGtzIGRyaW5raW5nLCBhbnl3YXksIHRvIGJlIHNvIHZlaGVtZW50bHkgb3Bwb3NlZD8gOikN
Cg0K


From nobody Thu Oct 16 07:08:51 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562941A1A24 for ; Thu, 16 Oct 2014 07:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAz6n_DFQs4Z for ; Thu, 16 Oct 2014 07:08:46 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88DAB1A00A7 for ; Thu, 16 Oct 2014 07:08:46 -0700 (PDT)
Received: from mail-yh0-f48.google.com (mail-yh0-f48.google.com [209.85.213.48]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0Mb8mZ-1XtHdo2utf-00Kd41; Thu, 16 Oct 2014 16:08:44 +0200
Received: by mail-yh0-f48.google.com with SMTP id v1so1963079yhn.35 for ; Thu, 16 Oct 2014 07:08:41 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.108.164 with SMTP id q24mr1727065yhg.131.1413468521604;  Thu, 16 Oct 2014 07:08:41 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Thu, 16 Oct 2014 07:08:41 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECC3@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E95AE.1030300@redhat.com>  <543F89C4.3020303@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECC3@USMBX1.msg.corp.akamai.com>
Date: Thu, 16 Oct 2014 16:08:41 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c1c9fc21c44105058ac90b
X-Provags-ID: V02:K0:5H/RIQI+lbx8M8dVPWBZvVmqu0WNu15ZzXcw1+DrmX3 iUrvGXdIv3qVp1Ly8j+v3/8B4p4HdTibKT3WdhYJzn8SLahzFD a14yw2JHEWuGZ1KuQ8rAoimyWtu3viv4tA5IO2zxU7DG89z4by 8/506cGWphqdPa0JT3Sv2+Hie7M0GYXFlbChulV0sH6xYirPKX dNah4G+b61aKg8uHHFr74qmKkJhnhnV4m83E3h/9mgvEYpiRLs 2CasFiGxyNN/ndWi7PBm/wACNcmuKyQ2ql1ov6OyEqs0eo0ouE d3YQ9L26F6AnFBDFq88OLNZfPLCkiINA0KCYXdoTRsFcxi3wWp B8tBEB7Lii3JrXsa+aPijx+cFq73AaTXuEOBtfoC5kofLQpb7x DgsDl1C/uTnmP7WJYzKLc23/0Zm39ZSp9HhRJIuQiy0WB65nL9 ic5ry
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VxXQXPcTDWbf4mefNSUAPEet9OU
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:08:48 -0000

--001a11c1c9fc21c44105058ac90b
Content-Type: text/plain; charset=UTF-8

Salz, Rich :


> > Should it retry without the SCSV?  I guess you mean "no way!", but this
> is
> > only implicit.
>


> I disagree with Bodo.  It's a user-agent issue. A browser might pop up a
> warning about the loss of privacy features and ask if it should proceed.


Good point. So there is indeed a potential scenario in which retrying
without the SCSV could be acceptable.

A "MUST NOT" for *automatic* such retries might be right, but then Rich's
example already shows that we'd probably be over-regulating by going into
such details. The current "SHOULD NOT" is quite clear -- implementors
*could* still get this wrong, but would adding a "MUST NOT" for retries of
retries really make any difference?

(We'd end up with a more complexly written spec, which is not desirable
without good justification.)

--001a11c1c9fc21c44105058ac90b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Salz=
, Rich <rsalz@akamai.com>:
=C2=A0

> Should it retry without the SCSV?=C2=A0 I guess you mean "no way!=
", but this is

> only implicit.
=C2=A0

I disagree with Bodo.=C2=A0 It's a user-agent issue. A browser m=
ight pop up a warning about the loss of privacy features and ask if it shou=
ld proceed.

Good point. So there is indeed =
a potential scenario in which retrying without the SCSV could be acceptable=
.

A "MUST NOT" for *automatic* such retr=
ies might be right, but then Rich's example already shows that we'd=
 probably be over-regulating by going into such details. The current "=
SHOULD NOT" is quite clear -- implementors *could* still get this wron=
g, but would adding a "MUST NOT" for retries of retries really ma=
ke any difference?

(We'd end up with a more co=
mplexly written spec, which is not desirable without good justification.)




--001a11c1c9fc21c44105058ac90b--


From nobody Thu Oct 16 07:19:46 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17511A1AB3 for ; Thu, 16 Oct 2014 07:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c9gtHj51J0r for ; Thu, 16 Oct 2014 07:19:38 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CBAE11A1A6C for ; Thu, 16 Oct 2014 07:19:37 -0700 (PDT)
Received: from [10.70.10.120] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 587CBF984 for ; Thu, 16 Oct 2014 10:19:33 -0400 (EDT)
Message-ID: <543FD3E9.4010208@fifthhorseman.net>
Date: Thu, 16 Oct 2014 10:19:21 -0400
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0
MIME-Version: 1.0
To: "tls@ietf.org" 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>  <20141015140158.41a1faf8@pc.my-domain> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com> 
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BTB8sGFmhbgo7kEH4jiUl5aEDjWNtKDO7"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vea43RLAZE-EDuo2nwliarClFGk
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:19:43 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--BTB8sGFmhbgo7kEH4jiUl5aEDjWNtKDO7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 10/15/2014 04:42 PM, Brian Smith wrote:
> If TLS 1.3 is still planning to use the version negotiation mechanism
> to negotiate TLS 1.3, then that's a defect in TLS 1.3, for this
> reason. That defect should be addressed so that the downgrade SCSV
> will be a non-issue for TLS 1.3.

Sorry, can you clarify what you mean by this?

What mechanism *should* peers use to negotiate TLS 1.3 if not the
standard TLS version negotiation mechanism?

How should we address this in TLS 1.3?

	--dkg


--BTB8sGFmhbgo7kEH4jiUl5aEDjWNtKDO7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJUP9PpXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcalAQAMoQg1KzHP9B7drJdlIFjkYt
Na4bcpkJRTmtjeEeeUJg+4vJ+ePsLgE3Ydb+tPmfyhm1uVThpyoJbmRk9p/W0CNe
u0NGM9JsFBDM1pFVgHRGU/Xyt4bDx/iQBO/OhtfKEOm99auz57YOHHYilnXiNzFu
WMtdY/J3P15aB0HcgqVxJpGVp/HnIZh4EyNmxADmZDrDb7OmD9Oj8BxIEd7u+yA1
Msq5ShY5uek67ZnZQXmf+3IEbdIl6rsPOj0POtryanns8VIAPFovE2whn8kiQyW3
zZ1Y4Elrnk/RnXYJgxcBemHj3HXWxRMntpN9f98tfZhY+zxMxatn0p+YFUBWMD5w
P3RKWnj8NdwpFgQr7JtG0taxb5O5B25kjjfOApPE7Cl2BpsqDB7rot+4h7J4hDr+
peBmkccNAY6FTTqIC9xklgL7INi4kOdq9LwhfrRM4HWjzoetCVQrKVNcLBbk+u9J
+z3VhTvFAuMXbY77Wk3EJsTab5ojikp9CfuIXVr+Pq5yKSu2AfxbYFgHr6chizCY
bgnHB5CxLIbyL6Ad/s6zs+y4yebKV96AEKQ39ksjHf/p41tPocReNvz1nW+7zqyB
WZGuFP4Et5uNOIs7VzTI4YBZgv/kDQGxPDUq2M21OsJhbhOlVUWCsL0QTyYsSChC
24jLLwuxPqEe7rQDJ2ha
=phod
-----END PGP SIGNATURE-----

--BTB8sGFmhbgo7kEH4jiUl5aEDjWNtKDO7--


From nobody Thu Oct 16 07:20:22 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E491B1A1A7D for ; Thu, 16 Oct 2014 07:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IV06HR1GkTnF for ; Thu, 16 Oct 2014 07:20:17 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D9E1A1B04 for ; Thu, 16 Oct 2014 07:20:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=4s57MOqXnAJvcjlBvPQgXLnqalylqKOddstXJ1t+yZk=;  b=DNBZm+yyqFwVl5la1vgQlKI5QIoRS+N4iqhKvXX9ifbEeVHoAynvqrV2CC9Hq+DoHCqu2ojndGdQoQEayGInCUT6U3pYZ41OrbbHcAObdw82SvHof/gicIitpUkHS+VYcEllRO7NduDAOjwjlKb7iaHl2/lSYmFl/xIG9rUZU/o=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XeluE-0002O4-OK; Thu, 16 Oct 2014 16:19:55 +0200
Message-ID: <543FD40E.9070405@polarssl.org>
Date: Thu, 16 Oct 2014 16:19:58 +0200
From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>	 <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com>	 <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com>	 <543E9C9F.5050104@redhat.com>	 <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com>	 <543E9FFA.5030102@redhat.com>	 	 	 <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org>	 <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZmlWXwrATV1Z4mA2RWwY6Ut_ha4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:20:18 -0000

On 16/10/2014 16:04, Nikos Mavrogiannopoulos wrote:
> On Thu, 2014-10-16 at 15:48 +0200, Manuel Pégourié-Gonnard wrote:
> 
>>> A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV 
>>> unconditionally.  This client would break once servers start supporting 
>>> TLS 1.3.  That's just one example of what could go wrong which could not 
>>> go wrong before.
>>>
>> I'm sorry, but wouldn't that be very stupid of the client? Maybe the draft could
>> include wording that clients MUST NOT do that, to be extra clear, but IMHO it's
>> already quite clear.
> 
> Of course, but isn't this issue that SCSV is trying to fix in the first
> place? Isn't the SCSV's reason of existance the fact that there are some
> buggy servers that cannot handle TLS protocol version negotiation? Why
> should we assume that buggy clients are impossible to happen?
> 
That's probably a good argument for mentioning it explicitly in the spec.

Maybe also mention that TLS implementations must not include this SCSV unless
explicitly requested to do so by the application, to prevent false good ideas
such as "let's include FALLBACK_SCSV automatically when the version we're
offering is less than the highest version we support" (which also should be
clear by reading the spec, but who knows).

I might be overly optimistic, but I hope that people implementing client
work-arounds made necessary by the existence of buggy servers are able and
willing to correctly implement a short a simple spec without adding bugs.

Manuel.


From nobody Thu Oct 16 07:28:33 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A66C1A1A6C for ; Thu, 16 Oct 2014 07:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.612
X-Spam-Level: 
X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLfFtNCSL3xr for ; Thu, 16 Oct 2014 07:28:29 -0700 (PDT)
Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293881A1A28 for ; Thu, 16 Oct 2014 07:28:29 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s9GESPMZ005685; Thu, 16 Oct 2014 10:28:25 -0400
Date: Thu, 16 Oct 2014 10:28:25 -0400 (EDT)
From: Hubert Kario 
To: Manuel =?utf-8?Q?P=C3=A9gouri=C3=A9-Gonnard?= 
Message-ID: <50007956.12601054.1413469705233.JavaMail.zimbra@redhat.com>
In-Reply-To: <543FCC90.7020408@polarssl.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.5.82.7]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922)
Thread-Topic: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: UzFvmGXgfeJ+fD1OR7x9fukXA9suEw==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4Ry3bFdYxrjZIt9VWRbO6beEidQ
Cc: Florian Weimer , tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:28:31 -0000

----- Original Message -----
> From: "Manuel P=C3=A9gouri=C3=A9-Gonnard" 
> To: "Florian Weimer" , "Martin Thomson" , "Bodo Moeller"
> 
> Cc: tls@ietf.org
> Sent: Thursday, 16 October, 2014 3:48:00 PM
> Subject: Re: [TLS] Working Group Last Call for=09draft-ietf-tls-downgrade=
-scsv-00
>=20
> On 16/10/2014 15:41, Florian Weimer wrote:
> > On 10/16/2014 12:40 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote:
> >> On 16/10/2014 12:06, Florian Weimer wrote:
> >>> Interesting things will start to happen once there is TLS 1.3.
> >>> TLS_FALLBACK_SCSV could really complicate its deployment.
> >>>
> >> I'm afraid I don't understand which interesting things you're referrin=
g
> >> to.
> >> Could you please elaborate on that?
> >>
> > A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV
> > unconditionally.  This client would break once servers start supporting
> > TLS 1.3.  That's just one example of what could go wrong which could no=
t
> > go wrong before.
> >=20
> I'm sorry, but wouldn't that be very stupid of the client? Maybe the draf=
t
> could
> include wording that clients MUST NOT do that, to be extra clear, but IMH=
O
> it's
> already quite clear.
>=20
> Besides clients doing this stupid thing, do you see other bad things rela=
ted
> to
> FALLBACK_SCSV that could happen when TLS 1.3 will start being deployed?

I don't see any.

Both NSS and OpenSSL when they receive TLS1.2 client hello with this SCSV
accept and continue connection.

Both NSS and OpenSSL when they are limited by configuration to a lower prot=
ocol
version (e.g. TLS1.0) and receive Client Hello with the same or higher vers=
ion
and this SCSV accept the connection.

In other words. If, for any reason, a future client (one that supports TLS1=
.3)
decides that it needs to downgrade the connection (and indicate that by add=
ing
the SCSV) to interoperate with current implementations, it will work correc=
tly.

Of course, if a client sets this SCSV always, even on first connection atte=
mpt,
then it will fail after the server upgrades to TLS1.3, or it uses the libra=
ry
that doesn't support higher protocol versions (like 0.9.8), but that's
incorrect use of the SCSV.
--=20
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hkario@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic


From nobody Thu Oct 16 07:32:04 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0F21A1B11 for ; Thu, 16 Oct 2014 07:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.612
X-Spam-Level: 
X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aEWBlj4HOda for ; Thu, 16 Oct 2014 07:32:00 -0700 (PDT)
Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCBA1A1A7F for ; Thu, 16 Oct 2014 07:30:45 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s9GEUiC8007871; Thu, 16 Oct 2014 10:30:44 -0400
Date: Thu, 16 Oct 2014 10:30:44 -0400 (EDT)
From: Hubert Kario 
To: Manuel =?utf-8?Q?P=C3=A9gouri=C3=A9-Gonnard?= 
Message-ID: <1135904896.12603096.1413469844673.JavaMail.zimbra@redhat.com>
In-Reply-To: <50007956.12601054.1413469705233.JavaMail.zimbra@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <50007956.12601054.1413469705233.JavaMail.zimbra@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.5.82.7]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922)
Thread-Topic: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: UzFvmGXgfeJ+fD1OR7x9fukXA9suE0ZjzGTM
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NDTBB5-S6qO5Ybuv4Tbo5eDO6JM
Cc: Florian Weimer , tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:32:02 -0000

----- Original Message -----
> From: "Hubert Kario" 
> To: "Manuel P=C3=A9gouri=C3=A9-Gonnard" 
> Cc: "Florian Weimer" , tls@ietf.org
> Sent: Thursday, 16 October, 2014 4:28:25 PM
> Subject: Re: [TLS] Working Group Last Call for=09draft-ietf-tls-downgrade=
-scsv-00
>=20
> ----- Original Message -----
> > From: "Manuel P=C3=A9gouri=C3=A9-Gonnard" 
> > To: "Florian Weimer" , "Martin Thomson"
> > , "Bodo Moeller"
> > 
> > Cc: tls@ietf.org
> > Sent: Thursday, 16 October, 2014 3:48:00 PM
> > Subject: Re: [TLS] Working Group Last Call for
> > =09draft-ietf-tls-downgrade-scsv-00
> >=20
> > On 16/10/2014 15:41, Florian Weimer wrote:
> > > On 10/16/2014 12:40 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote:
> > >> On 16/10/2014 12:06, Florian Weimer wrote:
> > >>> Interesting things will start to happen once there is TLS 1.3.
> > >>> TLS_FALLBACK_SCSV could really complicate its deployment.
> > >>>
> > >> I'm afraid I don't understand which interesting things you're referr=
ing
> > >> to.
> > >> Could you please elaborate on that?
> > >>
> > > A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV
> > > unconditionally.  This client would break once servers start supporti=
ng
> > > TLS 1.3.  That's just one example of what could go wrong which could =
not
> > > go wrong before.
> > >=20
> > I'm sorry, but wouldn't that be very stupid of the client? Maybe the dr=
aft
> > could
> > include wording that clients MUST NOT do that, to be extra clear, but I=
MHO
> > it's
> > already quite clear.
> >=20
> > Besides clients doing this stupid thing, do you see other bad things
> > related
> > to
> > FALLBACK_SCSV that could happen when TLS 1.3 will start being deployed?
>=20
> I don't see any.
>=20
> Both NSS and OpenSSL when they receive TLS1.2 client hello with this SCSV
> accept and continue connection.
>=20
> Both NSS and OpenSSL when they are limited by configuration to a lower
> protocol
> version (e.g. TLS1.0) and receive Client Hello with the same or higher
> version
> and this SCSV accept the connection.
>=20
> In other words. If, for any reason, a future client (one that supports
> TLS1.3)
> decides that it needs to downgrade the connection (and indicate that by
> adding
> the SCSV) to interoperate with current implementations, it will work
> correctly.
>=20
> Of course, if a client sets this SCSV always, even on first connection
> attempt,
> then it will fail after the server upgrades to TLS1.3, or it uses the lib=
rary
> that doesn't support higher protocol versions (like 0.9.8), but that's

like openssl 0.9.8*

> incorrect use of the SCSV.
> --
> Regards,
> Hubert Kario
> Quality Engineer, QE BaseOS Security team
> Email: hkario@redhat.com
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>=20

--=20
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hkario@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic


From nobody Thu Oct 16 07:34:20 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8741A1B01 for ; Thu, 16 Oct 2014 07:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DiRNnZKQ3Jw for ; Thu, 16 Oct 2014 07:34:17 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D14341A1A7F for ; Thu, 16 Oct 2014 07:34:16 -0700 (PDT)
Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0MC7ge-1XW0gg1wTw-008rlH; Thu, 16 Oct 2014 16:34:14 +0200
Received: by mail-yk0-f180.google.com with SMTP id 142so1173571ykq.25 for ; Thu, 16 Oct 2014 07:34:11 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.26.229 with SMTP id c65mr2024938yha.13.1413470051421; Thu, 16 Oct 2014 07:34:11 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Thu, 16 Oct 2014 07:34:11 -0700 (PDT)
In-Reply-To: <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>
Date: Thu, 16 Oct 2014 16:34:11 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c1c80850d6b405058b2442
X-Provags-ID: V02:K0:4j42ZuU35SbJ36y0CGbdd4s8mvsEIZEGNl7RR7bRXa7 52ITxjcpje0vKJF+jiiizeKNVdZMH2uwsFKVRQbJOUfIv/MmsW ewFl2glKJTkGRjkBE7m2tdPuyCDTd4H/93oHygCe0HkQk3vx7p tYivAHpcH2hzteSv1EQiCR5Vbg6qmQWlxveUORnuG+narV9y7b 7q2YNB9cn8BrqxyxCMU8Z11F3BPsPWWGt69Wzdee/qbqrkQN+j CNFTrcTnARX2hftdFlLGywg90rJnmkbzrsCUXLg3Ty6QbYziPq dgXPcL0hliBQmoxJzj/WjoY6CIXAAulZL8WWaXodAvyPs4/XiE HI94L/Z906bvH0hE3LUod3n30ald9M0smriZEvXyc0l/aqp49W i+mAdE+TsT22oxBz+XF4DGNEzZBQQIPTosS3rrzxEI9ajGJ+uk 8K/t6
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DdftWarEraFpkYhUFXUBdkPX0Ak
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:34:18 -0000

--001a11c1c80850d6b405058b2442
Content-Type: text/plain; charset=UTF-8

Nikos Mavrogiannopoulos :

> > A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV
> > > unconditionally.  This client would break once servers start supporting
> > > TLS 1.3.  That's just one example of what could go wrong which could
> not
> > > go wrong before.
>


> > I'm sorry, but wouldn't that be very stupid of the client? Maybe the
> draft could
> > include wording that clients MUST NOT do that, to be extra clear, but
> IMHO it's
> > already quite clear.
>


> Of course, but isn't this issue that SCSV is trying to fix in the first
> place? Isn't the SCSV's reason of existance the fact that there are some
> buggy servers that cannot handle TLS protocol version negotiation? Why
> should we assume that buggy clients are impossible to happen?


It's not *completely* inconceivable that this could happen -- regardless of
which client or server behavior is newly introduced, there's always *some*
chance that it might not work well with some buggy peer.

When writing the TLS_FALLBACK_SCSV specification, I was thus aiming to keep
it simple enough so that implementors would be extremely unlikely to get it
wrong (at least once there's some base deployment of clients and servers so
that basic interoperability tests will immediately expose large classes of
potential bugs, which should by now be the case). Do you seriously think
that implementors might end up sending TLS_FALLBACK_SCVS unconditionally?
If so, do you think that those implementors would be capable of avoiding
other more subtle bugs, and overall to create a mostly usable and possibly
even reasonably secure product? (I can't help thinking that if a client is
*that* broken, we'd probably be doing its users a favor by having all
handshakes fail.)

More importantly, if there were no fallback retries and thus no need for
TLS_FALLBACK_SCSV, how could that *possibly* make it *easier* to deploy TLS
1.3 given that buggy peers may be around?

Bodo

--001a11c1c80850d6b405058b2442
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Niko=
s Mavrogiannopoulos <nmav@redhat.com>:


> > A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV

> > unconditionally.=C2=A0 This client would break once servers start=
 supporting

> > TLS 1.3.=C2=A0 That's just one example of what could go wrong=
 which could not

> > go wrong before.
=C2=A0

> I'm sorry, but wouldn't that be very stupid of the client? May=
be the draft could

> include wording that clients MUST NOT do that, to be extra clear, but =
IMHO it's

> already quite clear.
=C2=A0

Of course, but isn't this issue that SCSV is trying to fix in th=
e first

place? Isn't the SCSV's reason of existance the fact that there are=
 some

buggy servers that cannot handle TLS protocol version negotiation? Why

should we assume that buggy clients are impossible to happen?<=
div>
It's not *completely* inconceivable that this could =
happen -- regardless of which client or server behavior is newly introduced=
, there's always *some* chance that it might not work well with some bu=
ggy peer.

When writing the TLS_FALLBACK_SCSV speci=
fication, I was thus aiming to keep it simple enough so that implementors w=
ould be extremely unlikely to get it wrong (at least once there's some =
base deployment of clients and servers so that basic interoperability tests=
 will immediately expose large classes of potential bugs, which should by n=
ow be the case). Do you seriously think that implementors might end up send=
ing TLS_FALLBACK_SCVS unconditionally? If so, do you think that those imple=
mentors would be capable of avoiding other more subtle bugs, and overall to=
 create a mostly usable and possibly even reasonably secure product? (I can=
't help thinking that if a client is *that* broken, we'd probably b=
e doing its users a favor by having all handshakes fail.)

More importantly, if there were no fallback retries and thus no nee=
d for TLS_FALLBACK_SCSV, how could that *possibly* make it *easier* to depl=
oy TLS 1.3 given that buggy peers may be around?

B=
odo



--001a11c1c80850d6b405058b2442--


From nobody Thu Oct 16 07:55:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7925D1A1B9A for ; Thu, 16 Oct 2014 07:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhn0fh9PgQ2C for ; Thu, 16 Oct 2014 07:55:07 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2024A1A1BE0 for ; Thu, 16 Oct 2014 07:55:07 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9GEt6sN012503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 16 Oct 2014 10:55:06 -0400
Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9GEt54B000829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 16 Oct 2014 10:55:06 -0400
Message-ID: <543FDC48.1060908@redhat.com>
Date: Thu, 16 Oct 2014 16:55:04 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Zhf_GoWK12MNVzJQpfkOrQBhxJQ
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:55:08 -0000

On 09/26/2014 08:41 AM, Martin Thomson wrote:
> On 26 September 2014 05:00, Joseph Salowey (jsalowey)
>  wrote:
>> This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your comments to the list by Friday, October 17, 2014.
>
> I've implemented this specification,

I have now implemented it as well.

One interoperability issue I encountered is that I initially sent a 
protocol version in the inappropriate_fallback alert that the OpenSSL 
client could not process because the protocol version had not been 
negotiated at this stage.  (This issue was also present in the code for 
the renegotiation SCSV.)  This is an ambiguity in the original TLS 
specification, I think, but perhaps the draft should say that you SHOULD 
send back the version used by the client.

-- 
Florian Weimer / Red Hat Product Security


From nobody Thu Oct 16 09:07:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FB31A3BA5 for ; Thu, 16 Oct 2014 09:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPcFUWyhdYpa for ; Thu, 16 Oct 2014 09:07:11 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9589F1A1C05 for ; Thu, 16 Oct 2014 09:07:10 -0700 (PDT)
Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0Ls9Wx-1YIQ3n0zjL-013sqP; Thu, 16 Oct 2014 18:07:08 +0200
Received: by mail-yh0-f44.google.com with SMTP id i57so2115620yha.31 for ; Thu, 16 Oct 2014 09:07:04 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.191.230 with SMTP id g66mr1879263yhn.27.1413475624121; Thu, 16 Oct 2014 09:07:04 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Thu, 16 Oct 2014 09:07:04 -0700 (PDT)
In-Reply-To: <543FDC48.1060908@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>  <543FDC48.1060908@redhat.com>
Date: Thu, 16 Oct 2014 18:07:04 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=20cf305b1082797c2a05058c70d4
X-Provags-ID: V02:K0:e1P7ECdGgwXbzuPkWvzeIF4DZoDi6LcLmHuhdW/osL6 i8ODXhIpYMEy+xuLKQyrkXYQpGUuZn2WLfWSTSxVkEVEZvDyF+ lpEIsdltU/MOIV48+Wv2btFg+e6J/INX23iTfkaZGBBNvqisD8 xJcxB8hapMP4vMWl4d9qlSJ7rx2GrhmMfKGobczBkfSck8i6Vo E8OLC5JRXmVrNvvdSe2H9lSdeSK46BRc3k55XKOmmU30g+Bpyc EREVE04m5RDfyv8r8kIVpg6okiDbZAxB4DG++Go48Ns7QOuNpk +DpoHutIEDU6nh872SNR1VZ7RgLwPpQ6ZxM/ZcHTawst7HzV6w 26tjihFVPeBto21rAQkue2vV8AIDjHr34z0Me4JV/fq1s0qRfd uK+9qS7NF65XzMyuAvxECpbpQr169teXi4BZveFuW2oKkdm9xw oPrvS
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H4k-d9QC_W6UI3SVedMCVhRhq7I
Cc: Florian Weimer 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 16:07:12 -0000

--20cf305b1082797c2a05058c70d4
Content-Type: text/plain; charset=UTF-8

Florian Weimer :

One interoperability issue I encountered is that I initially sent a
> protocol version in the inappropriate_fallback alert that the OpenSSL
> client could not process because the protocol version had not been
> negotiated at this stage.  (This issue was also present in the code for the
> renegotiation SCSV.)  This is an ambiguity in the original TLS
> specification, I think, but perhaps the draft should say that you SHOULD
> send back the version used by the client.


Thanks for the comment. Is this different from other fatal alerts that the
server might be sending in direct response to the ClientHello -- such as
handshake_failure, or even protocol_version?

Maybe it wouldn't hurt to explicitly say that if the client's version is
supported by the server but rejected due to the SCSV, that's the version to
use for the alert. But then record-layer version numbers are already a
muddy issue as is; I wouldn't want to specify side aspects of behavior that
may be incompatible, or utterly confusing if read in conjunction, with the
guidance on record-layer version numbers provided by the TLS specifications.

Bodo

--20cf305b1082797c2a05058c70d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Flor=
ian Weimer <fweimer@redhat.com>:


One interoperability issue I encountered is that I initially sent a protoco=
l version in the inappropriate_fallback alert that the OpenSSL client could=
 not process because the protocol version had not been negotiated at this s=
tage.=C2=A0 (This issue was also present in the code for the renegotiation =
SCSV.)=C2=A0 This is an ambiguity in the original TLS specification, I thin=
k, but perhaps the draft should say that you SHOULD send back the version u=
sed by the client.

Thanks for the comment. =
Is this different from other fatal alerts that the server might be sending =
in direct response to the ClientHello -- such as handshake_failure, or even=
 protocol_version?

Maybe it wouldn't hurt=
 to explicitly say that if the client's version is supported by the ser=
ver but rejected due to the SCSV, that's the version to use for the ale=
rt. But then record-layer version numbers are already a muddy issue as is; =
I wouldn't want to specify side aspects of behavior that may be incompa=
tible, or utterly confusing if read in conjunction, with the guidance on re=
cord-layer version numbers provided by the TLS specifications.
=


<=
span style=3D"font-size:1em;color:rgb(0,0,0)">Bodo



--20cf305b1082797c2a05058c70d4--


From nobody Thu Oct 16 09:29:13 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3801A87D0 for ; Thu, 16 Oct 2014 09:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcd1Qwz_yrxG for ; Thu, 16 Oct 2014 09:29:07 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5631A87D4 for ; Thu, 16 Oct 2014 09:28:57 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id p9so3118494lbv.19 for ; Thu, 16 Oct 2014 09:28:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kzmScvycX/ugBzaOjU1lTHFwymmZ036A1E1spyg9Flw=; b=OQ4vOM54c22cEwPcW8Ed81aGvqcTRT95CihDe13dDkARLke8wcgs4PSsPNDAHVyNYX PRmIIMjZtPNjNKqg/NjoEMv+f6GzJUDpREnoiyqc4GZSM2AMe+4bMWPrI4dhoKcOPm+m PJA1g4YDBTwvlvSfkvfdbs6pSH4PkwVTXVOArepqrHKEJpmT9yawSHHCQ3ODbkHntwEl yAXgG0mZZ7kwo3GW65jxzI0kc3V6/mlAHWpT+oVEoCfQZwALZ3IOoRyPLodjwpy4sSDZ xbp8zEDnRJxbedBSZ3RFoUwzpln9oxHyb5EaIj4UpCqr4Pz0+R+z2Y6Y4HEJDEbNJTU4 DWQg==
MIME-Version: 1.0
X-Received: by 10.112.57.227 with SMTP id l3mr2825061lbq.68.1413476936036; Thu, 16 Oct 2014 09:28:56 -0700 (PDT)
Received: by 10.112.29.51 with HTTP; Thu, 16 Oct 2014 09:28:55 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>  <543FDC48.1060908@redhat.com> 
Date: Thu, 16 Oct 2014 18:28:55 +0200
Message-ID: 
From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= 
To: Bodo Moeller 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xWn0RKvIeNJtSuxVldMQMHeIMDg
Cc: Florian Weimer , "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 16:29:08 -0000

On Thu, Oct 16, 2014 at 6:07 PM, Bodo Moeller  wrote:
> Florian Weimer :
>
>> One interoperability issue I encountered is that I initially sent a
>> protocol version in the inappropriate_fallback alert that the OpenSSL cl=
ient
>> could not process because the protocol version had not been negotiated a=
t
>> this stage.  (This issue was also present in the code for the renegotiat=
ion
>> SCSV.)  This is an ambiguity in the original TLS specification, I think,=
 but
>> perhaps the draft should say that you SHOULD send back the version used =
by
>> the client.
>
> Thanks for the comment. Is this different from other fatal alerts that th=
e
> server might be sending in direct response to the ClientHello -- such as
> handshake_failure, or even protocol_version?

Not as far as I can see.

> Maybe it wouldn't hurt to explicitly say that if the client's version is
> supported by the server but rejected due to the SCSV, that's the version =
to
> use for the alert. But then record-layer version numbers are already a mu=
ddy
> issue as is; I wouldn't want to specify side aspects of behavior that may=
 be
> incompatible, or utterly confusing if read in conjunction, with the guida=
nce
> on record-layer version numbers provided by the TLS specifications.

The way I've done it is to send early alerts as a packet with
min(client_version, server_max_version), as sending packets indicating
a newer version than the server actually supports seems a bit iffy. Of
course in the specific case of inappropriate_fallback and the
tls_fallback_scsv, for a correct server implementation the
client_version will always be less than the server_max_version as
otherwise the alert wouldn't be sent, so the two end up with the same
result.

--=20
Henrik Grubbstr=C3=B6m                                       grubba@grubba.=
org
Roxen Internet Software AB                              grubba@roxen.com


From nobody Thu Oct 16 11:36:52 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54631A701C for ; Thu, 16 Oct 2014 11:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmDSds1_WKnC for ; Thu, 16 Oct 2014 11:36:47 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDD81A011E for ; Thu, 16 Oct 2014 11:36:47 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 47DB5285AB; Thu, 16 Oct 2014 18:36:46 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 33966285A5; Thu, 16 Oct 2014 18:36:46 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 2EF2A2027; Thu, 16 Oct 2014 18:36:46 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 16 Oct 2014 14:36:33 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Thu, 16 Oct 2014 14:36:32 -0400
From: "Salz, Rich" 
To: Bodo Moeller , "tls@ietf.org" 
Date: Thu, 16 Oct 2014 14:36:31 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/pUAY6ES/pq+jCRpiV932lIz5YcwAIAb2w
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C40ED@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C40EDUSMBX1msgcorp_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/chOsygv2pNs3Ev5K4f2WxXFUOYA
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 18:36:49 -0000

--_000_2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C40EDUSMBX1msgcorp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SG93IGNhbiB5b3UgYWx3YXlzIHNlbmQgU0NTViB3aGVuIHRoZSBkYXJuIG5hbWUgc2F5cyDigJxG
QUxMQkFDS+KAnSA/Pz8NCg0KLS0NClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlciwgQWthbWFp
IFRlY2hub2xvZ2llcw0KSU06IHJzYWx6QGphYmJlci5tZTxtYWlsdG86cnNhbHpAamFiYmVyLm1l
PiBUd2l0dGVyOiBSaWNoU2Fseg0K

--_000_2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C40EDUSMBX1msgcorp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw
YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw
bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE
O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx
MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg
Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F
Ti1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhvdyBjYW4geW91IGFsd2F5cyBz
ZW5kIFNDU1Ygd2hlbiB0aGUgZGFybiBuYW1lIHNheXMg4oCcRkFMTEJBQ0vigJ0gPz8/PG86cD48
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj
b2xvcjojMUY0OTdEJz4tLcKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt
YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXIsIEFr
YW1haSBUZWNobm9sb2dpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SU06IDxhIGhyZWY9Im1haWx0bzpyc2FsekBqYWJiZXIu
bWUiPjxzcGFuIHN0eWxlPSdjb2xvcjpibHVlJz5yc2FsekBqYWJiZXIubWU8L3NwYW4+PC9hPiBU
d2l0dGVyOiBSaWNoU2FsejxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2JvZHk+PC9odG1s
Pg==

--_000_2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C40EDUSMBX1msgcorp_--


From nobody Thu Oct 16 11:42:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD5D1A7015 for ; Thu, 16 Oct 2014 11:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PtSgsh9V9PW for ; Thu, 16 Oct 2014 11:42:42 -0700 (PDT)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210721A0199 for ; Thu, 16 Oct 2014 11:42:41 -0700 (PDT)
Received: by mail-lb0-f179.google.com with SMTP id l4so3321494lbv.38 for ; Thu, 16 Oct 2014 11:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yb73I78J6+M2Hu3ZpTAbYdDn4yCUVdKrHnK/dYpmur0=; b=Jcw7/u1sEdLVJpOOUKqo9UGkQxxm1fv/jMZQ0oN/WJofIqeAUcgvHgn5XFPNrDEYi2 RBLzUoMBfixmumeC0j9b21kCoM0SXKKd8E6q9gaqW+2vDH/XlpIhCxYg/CgkJBeCCcH9 0j2LvV2mGjqxuObLX8ZKTEMzWZtmxEfu2D3/dEDp2DIiYr28S3OKl2mGE43gQPDFancU aWfohfTBGKPE+z7Rj8bFhhC0pgDi2EgZ/XQ42jUAN78qeqDTXfiMJthLQnwwRcwCFJLn 7JlGgC7IpauKFq8GinKF8JVSvjOHy0YZZpB4725nDDWeeCIp1mlDWvwux/IzrWbFyqif H+OA==
MIME-Version: 1.0
X-Received: by 10.152.216.200 with SMTP id os8mr3509898lac.85.1413484960334; Thu, 16 Oct 2014 11:42:40 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Thu, 16 Oct 2014 11:42:40 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C40ED@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>  <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C40ED@USMBX1.msg.corp.akamai.com>
Date: Thu, 16 Oct 2014 11:42:40 -0700
Message-ID: 
From: Martin Thomson 
To: "Salz, Rich" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-Ly1GsyukMlz8kRhn89f25Oh7P4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 18:42:44 -0000

On 16 October 2014 11:36, Salz, Rich  wrote:
> How can you always send SCSV when the darn name says =E2=80=9CFALLBACK=E2=
=80=9D ???

In the same way you can stab yourself repeatedly in the eye with a sharp st=
ick.

I'm not particularly interested in entertaining willful
misinterpretations.  I trust that Bodo can correct any egregious
errors or misleading text.


From nobody Thu Oct 16 13:03:15 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B161A88CF for ; Thu, 16 Oct 2014 13:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.321
X-Spam-Level: 
X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MANGLED_LOW=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkOI-bhhuYku for ; Thu, 16 Oct 2014 13:03:13 -0700 (PDT)
Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FD21A88C8 for ; Thu, 16 Oct 2014 13:03:12 -0700 (PDT)
Received: by mail-oi0-f47.google.com with SMTP id a141so3270484oig.34 for ; Thu, 16 Oct 2014 13:03:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+KECksSBjoYZ2fNpABwJVDS0VkIKsCfYE30fJMpi2vA=; b=UOYMa/cRWkhjuKE3uY9WNOgxz0QHZV8P7BXKC7SdqvdGpsAZ0jFBQ2pVkc14mTLOMr 7QwBQJRxHLtC2mRuteKHAAJELqhJ16X4tiS9BdTUUDLmO1sBu5d7oZWfg6J/BwqM3TWE M1p5+Zsg2p96T9veZtkeBn6qUVSkLzfTpIJh5rKpNFDPWLHPyaCRJn1aa5+w+9gKQOjo FzjzcHXFaEpmA0Rzo4WBppEgY00pKxzpKOnl/K8FOIQqrXxNMID6Qq0ubuHuOgIkq/hC Jjm86GMauPRXG2n5VLqZE+ZnZwMe9G9D+ZCkO/idqWjVUm3+HQjivUbchUpPZwiRU6Ev q22w==
X-Gm-Message-State: ALoCoQkLT4AstCRvh6oITPw93ZOWNnusfVJKw0W2cSZKsYYxokx+cUXNuEuZJxsmujp3pOJyfSUl
MIME-Version: 1.0
X-Received: by 10.60.132.102 with SMTP id ot6mr2892544oeb.62.1413489792405; Thu, 16 Oct 2014 13:03:12 -0700 (PDT)
Received: by 10.76.93.9 with HTTP; Thu, 16 Oct 2014 13:03:12 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>  
Date: Thu, 16 Oct 2014 13:03:12 -0700
Message-ID: 
From: Brian Smith 
To: Bodo Moeller 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IEOIp1U7XYO8dY9jg9ChQOpOJis
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 20:03:14 -0000

On Thu, Oct 16, 2014 at 6:36 AM, Bodo Moeller  wrote:
> Brian Smith :
>
>> It seems like the draft should also advise clients that they MUST NOT
>> do the False Start optimization if the server does not choose the
>> maximum version of TLS that they support. For example, if the server
>> chooses a version less than ClientHello.client_version, or if the
>> client sent the TLS_FALLBACK_SCSV, then the client MUST NOT false
>> start. Currently the draft says nothing about this. Because of False
>> Start, there are several downgrades that are still possible even with
>> the current downgrade-SCSV-enabled Chrome and Firefox, for example.
>
> This isn't specific to fallback retries and certainly not to the
> TLS_FALLBACK_SCSV mechanism (it's exactly the same with the standard
> mechanism for protocol version negotiation), so I think an updated version
> of the False Start specification would be the right place to set any strict
> requirements for this. However, it would make sense to *mention* and discuss
> this aspect in the TLS_FALLBACK_SCSV document (non-normatively).

If version downgrades during False Start are to be tolerated, then at
a minimum the security considerations of this draft must point out
that the mechanism is simple to subvert (partially, at least) when
False Start is used.

> [As for the specifics, while I think this isn't really for the
> TLS_FALLBACK_SCSV specification to define, allowing False Start only with
> the *one* most recent protocol version appears too strict. Specifically,
> while deployment of a new protocol version is underway, clients may want to
> use False Start both with this new version and with the previous version --
> why downgrade the overall experience for those who enable the latest
> protocol version?]

My point is that, because the clients that do the non-secure fallback
are also doing false start, without some version negotiation
restrictions for false start, the server still has no control over the
minimum version of TLS that will be used, even if they implement the
downgrade SCSV as specified. Right now it isn't a known emergency
because browsers (at least Firefox and Chrome) don't allow a MitM to
downgrade a connection to SSL 3.0 during false start. However, what if
the server administrator wants to be more cautious than browsers are?

It is true that, as the TLS 1.3 draft is currently written, browsers
will have to do non-secure fallback to TLS 1.2 often when they enable
TLS 1.3. I agree, given that current situation, that that is something
that should be allowed. But, I disagree that it should be allowed to
let a MitM downgrade a connection all the way to TLS 1.0 w/ the False
Start mechanism, especially when the server has implemented the
downgrade SCSV in an attempt to prevent that.

>> In summary, the way it is defined, the downgrade SCSV is only helpful
>> in preventing a limit number of unspecified downgrade attacks when
>> used in conjunction with False Start. Also, the draft is based on the
>> premise that preventing version downgrade is useful for preventing
>> some cryptographic attacks, but it does not substantiate that. POODLE
>> and BEAST are evidence that the mechanism helps for some attacks. But,
>> is this mechanism actually effective for preventing any other class of
>> attacks, other than TLS 1.1 -> TLS 1.0 -> SSL 3.0 downgrade for CBC
>> cipher suites? The answer to this should be in the security
>> considerations.
>
> Well, what makes the TLS_FALLBACK_SCSV mechanism particularly valuable is
> that it can help protect you from attacks that no one is aware of yet. So
> enumerating concrete attacks sort of would be missing the point:
> TLS_FALLBACK_SCSV is mainly about those vulnerabilities that we *can't* list
> there yet. I can tell you *now* how you would have benefited from supporting
> TLS_FALLBACK_SCSV half a year ago.

Besides POODLE and BEAST? I do think it would be good to see some more examples.

Anyway, I'm not asking you to enumerate every possible attack that is
prevented with this mechanism. I'm asking for the downgrade SCSV
mechanism to be improved to prevent more attacks, or at least for the
limitations of the dowgrade SCSV mechanism to be documented more
clearly.

> That said, the question whether the mechanism has relevance for weaknesses
> other than those found in CBC cipher suites can be answered in the
> affirmative. For example, if clients fall back to SSL 3.0 without TLS
> extensions, they can't use ECDHE and thus may lose forward security.

No. When false start is allowed for RSA key exchange, the initial HTTP
request (including auth credentials), even if both sides implement the
downgrade SCSV correctly, an attacker can still force the client to
send the initial HTTP requests (with auth credentials) using a version
of its choosing and using RSA key exchange. In Chrome and Firefox, the
downgrade to RSA is prevented by their False Start policies, not by
the downgrade SCSV.

My point is that, without adding some restrictions on False Start, the
downgrade SCSV mechainsm is useless against any attack that would
succeed by being able to control what the client sends in its initial
application data. (Note that POODLE isn't such an attack, because it
only succeeds by being able to control what the server will decrypt,
not just what the client sends.)

Again, to be clear, I am not saving the downgrade SCSV is bad. I'm
saying it is surprising that the downgrade SCSV doesn't prevent
version downgrades, and that should be fixed.

Cheers,
Brian


From nobody Thu Oct 16 17:41:13 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9A61A9060 for ; Thu, 16 Oct 2014 17:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sV6Xn2eOoSXK for ; Thu, 16 Oct 2014 17:41:08 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0735F1A8860 for ; Thu, 16 Oct 2014 17:41:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413506468; x=1445042468; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=yrbXNTby/dFoZ8mwpVRg0Cf3/HF/Y00qIjsmHjtG+Wo=; b=aNF+Hh1rsjiWJT4aWBf7ENUd5D3C3DBInI6c5F/F1zUTsK6RfA/BqkD5 FKPrQJ3ck+cFw5xWLnWLg5RkHNvsBvn6Lwjp8DiaSrMquxvwQae9Iq14l FB6Cslz9jyzM64P6gVL6kaN2QtWwqzfEaKQ26+QiielVQepZoyy2nuwOa U=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="283831826"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 17 Oct 2014 13:41:02 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 13:41:02 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/powZeO/R9myECQCGVp8gk2dtRDQ==
Date: Fri, 17 Oct 2014 00:41:01 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9CD9B9@uxcn10-tdc05.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-p3aIeOdYpLBfzNqKRfdh4XAjd4
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 00:41:12 -0000

Florian Weimer  writes:=0A=
>On 09/26/2014 08:41 AM, Martin Thomson wrote:=0A=
>> I've implemented this specification,=0A=
>=0A=
>I have now implemented it as well.=0A=
=0A=
Are there any test servers up that we can bounce messages off?=0A=
=0A=
Peter.=


From nobody Thu Oct 16 18:03:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EAC1A907F for ; Thu, 16 Oct 2014 18:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id matvvmTkRje8 for ; Thu, 16 Oct 2014 18:03:11 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1901A9084 for ; Thu, 16 Oct 2014 18:03:10 -0700 (PDT)
Received: by mail-lb0-f169.google.com with SMTP id 10so3766306lbg.28 for ; Thu, 16 Oct 2014 18:03:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mad2LLc12z4S+TcjAoPerJ8xGtt1phXE9TjGbdta/oQ=; b=QxxtxTwctmfvvZ3mgwNnR04qLTQrrRk/dmqJ8BaAcrlzREE/AxcFpu0JHJNh4Ah6fe KAfrbEumYzOrestW22QoOdTXa0nb8N+ugtQ4aIFBNsn5UqXNhKt+DxmWB7te3c1gNpMs TgLG6gcizHtNVV0JEsTi0r89Pl4kxPWMwVm60wlBS05e1NiX4X9xS0HVy4G5SPticJ09 oTQTRoMJ5eQMcDDMsmZp0xIpeEvDBKVTdXr4Qu9gsr2UgrxT0u0J8brMeZivrUS8lsqx g0hrqTbRtx3s/TbO5sMTEloA7vWMYxsvadFz8MAc+s9OSAd/GkIalUCTYjSA/U0KRH5E WOLA==
MIME-Version: 1.0
X-Received: by 10.112.200.34 with SMTP id jp2mr5189341lbc.1.1413507789460; Thu, 16 Oct 2014 18:03:09 -0700 (PDT)
Sender: alangley@gmail.com
Received: by 10.112.241.103 with HTTP; Thu, 16 Oct 2014 18:03:09 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9CD9B9@uxcn10-tdc05.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C739B9CD9B9@uxcn10-tdc05.UoA.auckland.ac.nz>
Date: Thu, 16 Oct 2014 18:03:09 -0700
X-Google-Sender-Auth: o7WSjYcMo9pLlDylAguRSCmiHMA
Message-ID: 
From: Adam Langley 
To: Peter Gutmann 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AXAylZUV5N7cQ9VrTCTHd21m7C4
Cc: "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 01:03:13 -0000

On Thu, Oct 16, 2014 at 5:41 PM, Peter Gutmann
 wrote:
> Are there any test servers up that we can bounce messages off?

www.google.com should work. Also, s_server from OpenSSL 1.0.1j.


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org


From nobody Thu Oct 16 22:46:37 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C3A1A90BF for ; Thu, 16 Oct 2014 22:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUYDGNDAWV6V for ; Thu, 16 Oct 2014 22:46:34 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F071A90B4 for ; Thu, 16 Oct 2014 22:46:34 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id p9so90643lbv.35 for ; Thu, 16 Oct 2014 22:46:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5lQZBWWdmoj1RVj9pKvecjAyeQ9W7tK4mA+rYVqx+Xo=; b=IRnw0XWtF8yyfaX+jWmESG5n2lk2FV93RM2Aiqr86zkCY7fRUYB0zovEKWKaRnTUVi GCT0C0iXi/I5bpJ4jvKTBhT5IDuwZDYjwKKGpBBO+3ZH80ji/7rmE2PwpTLps+PPYzAp +13JZERr/z16xRh3Atf/rJScnvmMy7G3ytqfEVqzbBBo4/ZQuqw8p5YaqzZwiEF4n1Sv KKE1WayNpiODMTQJYzUQnblfQjILD9xTY4YQr2xVMNgxzm0vCj7Ws+Q+JIeN0ED9j37F H4vcGZZa9zEAXw/wpLXK0z1WP1y26tlZRFJIjgKfITlqBGJ+7BW/Fidyh5av/S/WTa4b HvsA==
MIME-Version: 1.0
X-Received: by 10.152.205.44 with SMTP id ld12mr6224926lac.53.1413524792510; Thu, 16 Oct 2014 22:46:32 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Thu, 16 Oct 2014 22:46:32 -0700 (PDT)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C739B9CD9B9@uxcn10-tdc05.UoA.auckland.ac.nz> 
Date: Thu, 16 Oct 2014 22:46:32 -0700
Message-ID: 
From: Martin Thomson 
To: Adam Langley 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zlQFG1_BCeHEZvJkKDIyAkqkOVY
Cc: "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 05:46:36 -0000

On 16 October 2014 18:03, Adam Langley  wrote:
> On Thu, Oct 16, 2014 at 5:41 PM, Peter Gutmann
>  wrote:
>> Are there any test servers up that we can bounce messages off?
>
> www.google.com should work. Also, s_server from OpenSSL 1.0.1j.

This might help if you are into kludgy testing:
https://bugzilla.mozilla.org/show_bug.cgi?id=1036737#c8


From nobody Fri Oct 17 01:00:06 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5EE1A9107 for ; Fri, 17 Oct 2014 01:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqM4ClnBiUnl for ; Fri, 17 Oct 2014 01:00:02 -0700 (PDT)
Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195C21A90FC for ; Fri, 17 Oct 2014 01:00:01 -0700 (PDT)
Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-09v.sys.comcast.net with comcast id 48001p0022S2Q5R01800xz; Fri, 17 Oct 2014 08:00:00 +0000
Received: from [192.168.1.2] ([71.202.164.227]) by resomta-ch2-16v.sys.comcast.net with comcast id 47zz1p0044uhcbK017zzEg; Fri, 17 Oct 2014 08:00:00 +0000
Message-ID: <5440CC7F.1020608@brainhub.org>
Date: Fri, 17 Oct 2014 00:59:59 -0700
From: Andrey Jivsov 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org>
In-Reply-To: <5438CFEA.7000401@brainhub.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413532800; bh=YhssBP6FDii5AHGA7c+ujbCFDCrZZYHJgUYO1LGHKME=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IzjtB18KiZlzbXj7PMK+TmFLkTspjdpfX9dObhDh0TnsXEkk6tBh1j0iPoPXyGKQj Icmvi+NbyN6PbvOflL5EVrSQB1YyX0j1jT4UHkkUdPWpgOLaeoXuYYqWVb0gWc0ysY s45TOBfY8vmKhGfBSpvWkANnzTaoAJHhQE6v9KkUzhrohHrWdwWhTghym3tPH/m9QV t7aVysQa5rBOlVSP5caEZ5liCs0/jfD6fLPC85+KSnU7LHiBmRNAANjTyRho3eOWY2 0MTwET65OWm0tsMyEUSQgVuYAAncssmdDdONSAE1K2agCs83vaC+Y5Uf7ZiB3ObYzs fFxRjjB/5I8Qw==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w6wfGpjsimx99gMvbgVxnLtSnJ8
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 08:00:04 -0000

(On handling of the downgrade to a recent versions of the protocols, 
i.e. TLS1.3 to 1.2 or TLS1.2 to TLS1.1.)

Today, for example,

    www.wellsfargo.com, citibank.com, and bankofamerica.com don't 
support TLS 1.1 and

    mozilla.com doesn't support TLS 1.2.

The draft -00 asks the server supporting TLS 1.2 to fail the TLS 1.1 in 
some cases, while significant amount of traffic on the Internet goes 
over TLS 1.0.

I propose the following change that allows to do exactly what rev -00 
says, but now enables more tolerant server behaviour.

The text captures the need to be more forceful on the lower (insecure) 
end of the SSL2.0 - TLS1.2 range, while being more tolerant with more 
recent (secure) versions.

 > 3. Server behaviour
 >
 > This section specifies server behaviour when receiving the
 > TLS_FALLBACK_SCSV cipher suite from a client in
 > ClientHello.cipher_suites.
 >
> When TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
> highest version of the protocol supported by the server is greater
> than the version indicated in ClientHello.client_version, this is an
> indication to the server that the client chose lower version of the
> protocol in its ClientHello message than the client is capable of
> negotiating.
 >
> When the server detects the above scenario, it MUST respond with an
> inappropriate_fallback alert when ClientHello.client_version
> indicates version  or lower and MAY respond with an
> inappropriate_fallback alert for higher versions of the protocol.

I would further propose to set  = SSL 3.0 and I accept to have it 
at TLS 1.0 as a second choice.

In the first case, it's easy to notice that if the server has disabled 
SSLv3 (and SSLv2) and tolerates TLS 1.0 and TLS 1.1, the server is 
compliant with the TLS_FALLBACK_SCSV.

If  = TLS 1.0, SSL3.0, SSL2.0 are disabled, the server may consider 
TLS 1.1 as acceptable (but also may choose to be intolerant of it + 
SCSV, although IMO this is undesirable today) but the server is required 
to issue inappropriate_fallback for TLS 1.0+SCSV. The server will need 
to implement parsing of SCSV in this case because it is required to 
distinguish TLS 1.0 from TLS 1.0+SCSV and have code to issue 
inappropriate_fallback.

Thank you.


From nobody Fri Oct 17 02:23:29 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78681ABD3D for ; Fri, 17 Oct 2014 02:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.612
X-Spam-Level: 
X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiT9DFH185s8 for ; Fri, 17 Oct 2014 02:23:25 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C161ABD3B for ; Fri, 17 Oct 2014 02:23:25 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9H9NKrD009047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 17 Oct 2014 05:23:20 -0400
Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9H9NIPu031200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 17 Oct 2014 05:23:19 -0400
Message-ID: <5440E005.6000607@redhat.com>
Date: Fri, 17 Oct 2014 11:23:17 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: "Salz, Rich" , =?windows-1252?Q?Manuel_P=E9gouri=E9?= =?windows-1252?Q?-Gonnard?= , Martin Thomson , Bodo Moeller 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/weEVAObW5357HCEEnwvRkoRjvdM
Cc: "tls@ietf.org" 
Subject: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 09:23:28 -0000

On 10/16/2014 03:44 PM, Salz, Rich wrote:
>> A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV
>> unconditionally.
>
> A widely deployed client might also start injecting line noise into the TLS stream.
>
> We can't control what buggy clients do.  That's not new.

You recently wrote about SSL_MODE_SEND_FALLBACK_SCSV, without any 
qualifications:

“I recommend that you always set that flag.”



Unfortunately, you are not the only one who makes this mistake.

I'm now convinced that the scenario I described is extremely likely. 
The problem, of course, is that you will not notice this bug in the 
client application until the server supports TLS 1.3, when it may be too 
late to fix it in the client.

It would be better to say that connections with TLS_FALLBACK_SCSV need 
to fail unconditionally in the server, independent of client and server 
protocol version.  This approach would essentially be a promise of the 
server to be version-tolerant (or a statement of having been updated 
recently, which hopefully amounts to the same thing).  The advantage 
that it doesn't come with the time bomb that has been built into the 
current draft.

-- 
Florian Weimer / Red Hat Product Security


From SRS0=LHIJ=7I=acm.org=bmoeller@srs.kundenserver.de  Fri Oct 17 02:56:36 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392421AC3B5 for ; Fri, 17 Oct 2014 02:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.362
X-Spam-Level: *
X-Spam-Status: No, score=1.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_LOW=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQJnPfVpag7X for ; Fri, 17 Oct 2014 02:56:34 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081AA1ABD39 for ; Fri, 17 Oct 2014 02:56:34 -0700 (PDT)
Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0M21dP-1XzUQu2ifz-00u1mz; Fri, 17 Oct 2014 11:56:32 +0200
Received: by mail-yk0-f170.google.com with SMTP id 20so201423yks.1 for ; Fri, 17 Oct 2014 02:56:28 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.203.114 with SMTP id e78mr10402247yho.47.1413539788350;  Fri, 17 Oct 2014 02:56:28 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Fri, 17 Oct 2014 02:56:28 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>   
Date: Fri, 17 Oct 2014 11:56:28 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0158c7c4f5f02405059b6056
X-Provags-ID: V02:K0:/++NlE5ixiuSWnzjj4kGorPuF6ZN96iPjUv+IsQ+B9l +qANbj8nHrrB6YHc3rpYewJmEofYWc/ozMaNDzd2iKxHdJHeWw 2fMwXDKSYAD6i0lT6yYrw26nxP7os0YZYtO1x6IUO5IE0UzGgQ 3YOByazMMVYcyh4crQAJ0+2yvgBbKkTQn7SSAyfkAjtJw2n3yO obf9OpW2Eum64rupKrXIldojFaeeTsGLOb6JplyxJSC9Ky+/kB DadpQnvHH/JOKuLBAEAzoCBbTXrpfbet3+rI4XluuY0DIyMpqw fKVkaNaacrmlHlpvEIbP4MJzQfe+3mgxavuY2cMaXXooM7hbGh aF51EK5AEj5NMKroTjUFL/7jBIH05owkM4rtDGrtN+eqtuTFsF LzqvRmbGrZiKUjJOCASe0xXKbyJZ+jIMSN9LNuvG0CpET4mZcU scKGy
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qom8bQHCUjqb_hlxJnlz2F5WG-k
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 10:41:25 -0000

--089e0158c7c4f5f02405059b6056
Content-Type: text/plain; charset=UTF-8

Brian Smith :

> Bodo Moeller  wrote:
> > Brian Smith :
>


> >> It seems like the draft should also advise clients that they MUST NOT
> >> do the False Start optimization if the server does not choose the
> >> maximum version of TLS that they support. For example, if the server
> >> chooses a version less than ClientHello.client_version, or if the
> >> client sent the TLS_FALLBACK_SCSV, then the client MUST NOT false
> >> start. Currently the draft says nothing about this. Because of False
> >> Start, there are several downgrades that are still possible even with
> >> the current downgrade-SCSV-enabled Chrome and Firefox, for example.
>


> > This isn't specific to fallback retries and certainly not to the
> > TLS_FALLBACK_SCSV mechanism (it's exactly the same with the standard
> > mechanism for protocol version negotiation), so I think an updated
> version
> > of the False Start specification would be the right place to set any
> strict
> > requirements for this. However, it would make sense to *mention* and
> discuss
> > this aspect in the TLS_FALLBACK_SCSV document (non-normatively).
>


> If version downgrades during False Start are to be tolerated, then at
> a minimum the security considerations of this draft must point out
> that the mechanism is simple to subvert (partially, at least) when
> False Start is used.
>

Exactly, but the detailed recommendations should go into an updated False
Start I-D instead; I can do that.  Specifically, that spec could say that
if the client sends TLS_FALLBACK_SCSV in the client hello, False Start
SHOULD be disabled for that handshake.  And then we'll also have to say
that the client similarly should not use False Start with any protocol
version for which it would send TLS_FALLBACK_SCSV in fallback retries
(since otherwise the former recommendation wouldn't achieve anything.)  The
TLS_FALLBACK_SCSV spec's Security Considerations, then, will include a
reminder that allowing False Start with older protocol versions can be
problematic, and that this is a (general) problem that TLS_FALLBACK_SCSV
can't address.

So, I believe that your suggestion for client behavior is absolutely spot
on. My point is just that the very same issue w.r.t. False Start and
version downgrades exists if the client doesn't do any fallback retries --
and those who implement such clients shouldn't have to read the
TLS_FALLBACK_SCSV spec to find out when to allow False Start: this belongs
into the False Start spec.


It is true that, as the TLS 1.3 draft is currently written, browsers
> will have to do non-secure fallback to TLS 1.2 often when they enable
> TLS 1.3. I agree, given that current situation, that that is something
> that should be allowed. But, I disagree that it should be allowed to
> let a MitM downgrade a connection all the way to TLS 1.0 w/ the False
> Start mechanism, especially when the server has implemented the
> downgrade SCSV in an attempt to prevent that.
>

Right.  (Except that I don't think that you *disagree* with me on this.)


[...]

> > That said, the question whether the mechanism has relevance for
> weaknesses
> > other than those found in CBC cipher suites can be answered in the
> > affirmative. For example, if clients fall back to SSL 3.0 without TLS
> > extensions, they can't use ECDHE and thus may lose forward security.
>

No. When false start is allowed for RSA key exchange, the initial HTTP
> request (including auth credentials), even if both sides implement the
> downgrade SCSV correctly, an attacker can still force the client to
> send the initial HTTP requests (with auth credentials) using a version
> of its choosing and using RSA key exchange. In Chrome and Firefox, the
> downgrade to RSA is prevented by their False Start policies, not by
> the downgrade SCSV.
>

Here I don't agree. The downgrade to RSA is prevented by having *both*
(don't allow False Start here, *and* use the downgrade SCSV). Not allowing
False Start wouldn't have helped at all without the SCSV for fallback
retries, and using the SCSV wouldn't have been a complete solution if False
Start was enabled with legacy protocols.


Again, to be clear, I am not saving the downgrade SCSV is bad. I'm
> saying it is surprising that the downgrade SCSV doesn't prevent
> version downgrades, and that should be fixed.


Right. I'll mention that potential surprise with False Start in
TLS_FALLBACK_SCSV Security Considerations, and specify how to avoid it in
the False Start specification.

Bodo

--089e0158c7c4f5f02405059b6056
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Bria=
n Smith <brian@briansmith.org>:
Bodo =
Moeller <bmoeller@acm.org> wr=
ote:

> Brian Smith <brian@briansmi=
th.org>:
=C2=A0

>> It seems like the draft should also advise clients that they MUST =
NOT

>> do the False Start optimization if the server does not choose the<=
br>
>> maximum version of TLS that they support. For example, if the serv=
er

>> chooses a version less than ClientHello.client_version, or if the<=
br>
>> client sent the TLS_FALLBACK_SCSV, then the client MUST NOT false<=
br>
>> start. Currently the draft says nothing about this. Because of Fal=
se

>> Start, there are several downgrades that are still possible even w=
ith

>> the current downgrade-SCSV-enabled Chrome and Firefox, for example=
.
=C2=A0

> This isn't specific to fallback retries and certainly not to the
> TLS_FALLBACK_SCSV mechanism (it's exactly the same with the standa=
rd

> mechanism for protocol version negotiation), so I think an updated ver=
sion

> of the False Start specification would be the right place to set any s=
trict

> requirements for this. However, it would make sense to *mention* and d=
iscuss

> this aspect in the TLS_FALLBACK_SCSV document (non-normatively).
=C2=A0

If version downgrades during False Start are to be tolerated, then at

a minimum the security considerations of this draft must point out

that the mechanism is simple to subvert (partially, at least) when

False Start is used.

Exactly, but the d=
etailed recommendations should go into an updated False Start I-D instead; =
I can do that.=C2=A0 Specifically, that spec could say that if the client s=
ends TLS_FALLBACK_SCSV in the client hello, False Start SHOULD be disabled =
for that handshake.=C2=A0 And then we'll also have to say that the clie=
nt similarly should not use False Start with any protocol version for which=
 it would send TLS_FALLBACK_SCSV in fallback retries (since otherwise the f=
ormer recommendation wouldn't achieve anything.) =C2=A0The TLS_FALLBACK=
_SCSV spec's Security Considerations, then, will include a reminder tha=
t allowing False Start with older protocol versions can be problematic, and=
 that this is a (general) problem that TLS_FALLBACK_SCSV can't address.=


So, I believe that your suggestion for client beh=
avior is absolutely spot on. My point is just that the very same issue w.r.=
t. False Start and version downgrades exists if the client doesn't do a=
ny fallback retries -- and those who implement such clients shouldn't h=
ave to read the TLS_FALLBACK_SCSV spec to find out when to allow False Star=
t: this belongs into the False Start spec.



It is true that, as the TLS 1.3 draft is currently written, browsers

will have to do non-secure fallback to TLS 1.2 often when they enable

TLS 1.3. I agree, given that current situation, that that is something

that should be allowed. But, I disagree that it should be allowed to

let a MitM downgrade a connection all the way to TLS 1.0 w/ the False

Start mechanism, especially when the server has implemented the

downgrade SCSV in an attempt to prevent that.

Right. =C2=A0(Except that I don't think that you *disagree* with=
 me on this.)


[...]

> That said, the question whether the mechanism has relevance for weakne=
sses

> other than those found in CBC cipher suites can be answered in the

> affirmative. For example, if clients fall back to SSL 3.0 without TLS<=
br>
> extensions, they can't use ECDHE and thus may lose forward securit=
y.


No. When false start is allowed for RSA key exchange, the initial HTTP

request (including auth credentials), even if both sides implement the

downgrade SCSV correctly, an attacker can still force the client to

send the initial HTTP requests (with auth credentials) using a version

of its choosing and using RSA key exchange. In Chrome and Firefox, the

downgrade to RSA is prevented by their False Start policies, not by

the downgrade SCSV.

Here I don't ag=
ree. The downgrade to RSA is prevented by having *both* (don't allow Fa=
lse Start here, *and* use the downgrade SCSV). Not allowing False Start wou=
ldn't have helped at all without the SCSV for fallback retries, and usi=
ng the SCSV wouldn't have been a complete solution if False Start was e=
nabled with legacy protocols.



Again, to be clear, I am not saving the downgrade SCSV is bad. I'm

saying it is surprising that the downgrade SCSV doesn't prevent

version downgrades, and that should be fixed.

Right. I'll mention that potential surprise with False Start in TLS_=
FALLBACK_SCSV Security Considerations, and specify how to avoid it in the F=
alse Start specification.

Bodo



--089e0158c7c4f5f02405059b6056--


From nobody Fri Oct 17 04:14:47 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1851F1AC3DC for ; Fri, 17 Oct 2014 04:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.612
X-Spam-Level: 
X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3maR2oSoFSVx for ; Fri, 17 Oct 2014 04:14:32 -0700 (PDT)
Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB281AC3D5 for ; Fri, 17 Oct 2014 04:14:32 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9HBEQqC025017; Fri, 17 Oct 2014 07:14:26 -0400
Date: Fri, 17 Oct 2014 07:14:26 -0400 (EDT)
From: Hubert Kario 
To: Florian Weimer 
Message-ID: <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>
In-Reply-To: <5440E005.6000607@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.5.82.7]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922)
Thread-Topic: The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: Yc+uBaMbuH5fRBJkOvsv1Ja/dIBIJg==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w94nSXC6BVExOIkxpJ5z6Ouyi5w
Cc: Manuel =?utf-8?Q?P=C3=A9gouri=C3=A9-Gonnard?= , tls@ietf.org
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 11:14:36 -0000

----- Original Message -----
> From: "Florian Weimer" 
> To: "Rich Salz" , "Manuel P=C3=A9gouri=C3=A9-Gonnard" <=
mpg@polarssl.org>, "Martin Thomson"
> , "Bodo Moeller" 
> Cc: tls@ietf.org
> Sent: Friday, 17 October, 2014 11:23:17 AM
> Subject: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group La=
st Call for
> draft-ietf-tls-downgrade-scsv-00)
>=20
> On 10/16/2014 03:44 PM, Salz, Rich wrote:
> >> A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV
> >> unconditionally.
> >
> > A widely deployed client might also start injecting line noise into the=
 TLS
> > stream.
> >
> > We can't control what buggy clients do.  That's not new.
>=20
> You recently wrote about SSL_MODE_SEND_FALLBACK_SCSV, without any
> qualifications:
>=20
> =E2=80=9CI recommend that you always set that flag.=E2=80=9D
>=20
> 
>=20
> Unfortunately, you are not the only one who makes this mistake.
>=20
> I'm now convinced that the scenario I described is extremely likely.
> The problem, of course, is that you will not notice this bug in the
> client application until the server supports TLS 1.3, when it may be too
> late to fix it in the client.
>=20
> It would be better to say that connections with TLS_FALLBACK_SCSV need
> to fail unconditionally in the server, independent of client and server
> protocol version.  This approach would essentially be a promise of the
> server to be version-tolerant (or a statement of having been updated
> recently, which hopefully amounts to the same thing).

But how can you test that the server really *is* tolerant to future
yet undefined protocol versions?

Sure, you can test if the code will accept a client hello with high
minor/major versions, but future versions may modify the initial hello
message in a way the programmers of the server didn't expect and that
actually crashes or generates a fatal error in the server (e.g. because
the server tries to parse whole hello message before looking at the
tls version).

Then to interoperate with such a server a browser would have to try
a client hello with lower version and without the SCSV to interoperate.
And we're in square zero...

>  The advantage
> that it doesn't come with the time bomb that has been built into the
> current draft.

While this is a possibility, I think the only thing we can do to prevent
that is to be explicit in the document:

"The client MUST NOT advertise TLS_FALLBACK_SCSV if it initiates connection
with the highest protocol version it supports."

--=20
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hkario@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic


From nobody Fri Oct 17 06:20:34 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB461ACDA3 for ; Fri, 17 Oct 2014 06:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikSJywGYjSW3 for ; Fri, 17 Oct 2014 06:20:19 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70AD01ACD7E for ; Fri, 17 Oct 2014 06:20:18 -0700 (PDT)
Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0LqlQA-1YJNt73FpK-00eJ6Z; Fri, 17 Oct 2014 15:20:16 +0200
Received: by mail-yk0-f180.google.com with SMTP id 142so323512ykq.39 for ; Fri, 17 Oct 2014 06:20:14 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.22.228 with SMTP id t64mr3672516yht.164.1413552014601; Fri, 17 Oct 2014 06:20:14 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Fri, 17 Oct 2014 06:20:14 -0700 (PDT)
In-Reply-To: <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>
Date: Fri, 17 Oct 2014 15:20:14 +0200
Message-ID: 
From: Bodo Moeller 
To: Hubert Kario 
Content-Type: multipart/alternative; boundary=e89a8f642a98b3b60d05059e395a
X-Provags-ID: V02:K0:qvIGLJK9g/pG1R5tdU6mhlKvJDNfWD5qa8ZTuD2DnUK RaCQ8gF3a7ZQrH6MYrXrv638xQrkvmUIfDSOEpw523R2iugkd2 wCMy0xoRPMKL5mHhuH3wcZ7IN14G7BmPOwWk+qbr4xy8xhC7vU LhD3LAT8BQp1gjb4euHp5RQDcaK53SwQyCEB0PE4vvcgx0eJvZ 9uF9tzpXqhbZszkNi+6gitf42Y0/92zpwC/XJWkRc7HnowLzHN p0LM6a2/BK4JD1z+3Je4hiUYM/szAevInR/ZgRH7XZCbbCmPgC MMZ5U4syiMBtFeie1s6dZ74GQyMBqfmx+2pkG1LScm1TDuJcjs JP8mSC7/Zy2v0YVSSyBwEjgwVFQUJnxZBnxUxjtsLlTST3yGAF /1mWBKd/WJ+yseSZDNbIS/hTs27ojNZKEvYIg2C/2kz7UXIYKS Vs4Qj
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LMc11K4C0pt3WZTOuhlX5wmyZcQ
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 13:20:27 -0000

--e89a8f642a98b3b60d05059e395a
Content-Type: text/plain; charset=UTF-8

Hubert Kario :


> [...] I think the only thing we can do to prevent
> that is to be explicit in the document:
>
> "The client MUST NOT advertise TLS_FALLBACK_SCSV if it initiates connection
> with the highest protocol version it supports."


Right, I think stating this explicitly in the spec is probably the right
thing to do (of course this has been the intended behavior all along).
Thanks.

(Arguably the OpenSSL API is too fragile, and SSL_MODE_SEND_FALLBACK_SCSV
should be ignored in this case. So clarifying that in the spec is not the
*only* thing we can do to prevent this.

Also, if a few HTTPS servers log information such as the User-Agent header
if they see a client hello advertising TLS 1.2 with TLS_FALLBACK_SCSV, that
could be used to track down any clients that still manage to get it wrong.
That seems more practical than using clients to find version-intolerant
servers, because for that you'd have to send TLS 1.3 or TLS 1.4 client
hellos before these protocols actually exist, and then wouldn't quite know
what to do in case the server actually chooses one of these versions.)

While I don't see any way to completely avoid interoperability failures in
the presence of potential bugs, I think this failure scenario (buggy
clients potentially sending TLS_FALLBACK_SCSV in every handshake) really
isn't as bad as the alternatives -- such as strictly expecting servers to
be version-tolerant for protocol versions they've never been tested with.
There's always *some* way how buggy implementations could break
interoperability.

Bodo

--e89a8f642a98b3b60d05059e395a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hube=
rt Kario <hkario@redhat.com>:
=C2=A0

[...] I think the only thing we can do to prevent

that is to be explicit in the document:



"The client MUST NOT advertise TLS_FALLBACK_SCSV if it initiates conne=
ction

with the highest protocol version it supports."

<=
/div>
Right, I think stating this explicitly in the spec is probably th=
e right thing to do (of course this has been the intended behavior all alon=
g). Thanks.

(Arguably the OpenSSL API is too fragi=
le, and=C2=A0SSL_MODE_SEND_FALLBACK_SCSV should be ignored in this case. So=
 clarifying that in the spec is not the *only* thing we can do to prevent t=
his.

Also, if a few HTTPS servers log information =
such as the User-Agent header if they see a client hello advertising TLS 1.=
2 with TLS_FALLBACK_SCSV, that could be used to track down any clients that=
 still manage to get it wrong. That seems more practical than using clients=
 to find version-intolerant servers, because for that you'd have to sen=
d TLS 1.3 or TLS 1.4 client hellos before these protocols actually exist, a=
nd then wouldn't quite know what to do in case the server actually choo=
ses one of these versions.)

While I don't see =
any way to completely avoid interoperability failures in the presence of po=
tential bugs, I think this failure scenario (buggy clients potentially send=
ing TLS_FALLBACK_SCSV in every handshake) really isn't as bad as the al=
ternatives -- such as strictly expecting servers to be version-tolerant for=
 protocol versions they've never been tested with. There's always *=
some* way how buggy implementations could break interoperability.

Bodo




--e89a8f642a98b3b60d05059e395a--


From nobody Fri Oct 17 06:40:30 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C781ACDF5 for ; Fri, 17 Oct 2014 06:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level: 
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OS4GgIbPJQxy for ; Fri, 17 Oct 2014 06:40:26 -0700 (PDT)
Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C101ACDF0 for ; Fri, 17 Oct 2014 06:40:26 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9HDeM3Y022757; Fri, 17 Oct 2014 09:40:22 -0400
Date: Fri, 17 Oct 2014 09:40:21 -0400 (EDT)
From: Hubert Kario 
To: Bodo Moeller 
Message-ID: <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com> 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_13104896_336762867.1413553221954"
X-Originating-IP: [10.5.82.7]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922)
Thread-Topic: The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: 3+ehLL7PgdlxwfsUvIMgxHHqC0ChYQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fPaGMN67e4ZlZoasSKWhCrN1rz8
Cc: tls@ietf.org
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 13:40:28 -0000

------=_Part_13104896_336762867.1413553221954
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

----- Original Message -----

> From: "Bodo Moeller" 
> To: "Hubert Kario" 
> Cc: tls@ietf.org
> Sent: Friday, 17 October, 2014 3:20:14 PM
> Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Grou=
p
> Last Call for draft-ietf-tls-downgrade-scsv-00)

> Hubert Kario < hkario@redhat.com > :

> > [...] I think the only thing we can do to prevent
>=20
> > that is to be explicit in the document:
>=20

> > "The client MUST NOT advertise TLS_FALLBACK_SCSV if it initiates connec=
tion
>=20
> > with the highest protocol version it supports."
>=20
> Right, I think stating this explicitly in the spec is probably the right
> thing to do (of course this has been the intended behavior all along).
> Thanks.

> (Arguably the OpenSSL API is too fragile, and SSL_MODE_SEND_FALLBACK_SCSV
> should be ignored in this case. So clarifying that in the spec is not the
> *only* thing we can do to prevent this.

NSS API does allow this too.=20

Thing is, we want to have a way to test if the servers are tolerant to futu=
re clients=20
that claim they had to downgrade. So having the ability to set TL1.2 with t=
his=20
SCSV is useful, just like is having an easy to use, widely distributed CLI =
tool=20
(openssl command) that can do this should help with testing and interoperab=
ility,=20
IMHO.=20

--=20
Regards,=20
Hubert Kario=20
Quality Engineer, QE BaseOS Security team=20
Email: hkario@redhat.com=20
Web: www.cz.redhat.com=20
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic=20

------=_Part_13104896_336762867.1413553221954
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


From: "Bodo Moeller" <bmoe=
ller@acm.org>
To: "Hubert Kario" <hkario@redhat.com>
=
Cc: tls@ietf.org
Sent: Friday, 17 October, 2014 3:20:14 PM=

Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Wor=
king Group Last Call for draft-ietf-tls-downgrade-scsv-00)

Hu=
bert Kario <hkario@redhat.com>:

[...] I think the only thing we can do to prevent

that is to be explicit in the document:


"The client MUST NOT advertise TLS_FALLBACK_SCSV if it initiates connection=


with the highest protocol version it supports."

=

Right, I think stating this explicitly in the spec is probably the rig=
ht thing to do (of course this has been the intended behavior all along). T=
hanks.

(Arguably the OpenSSL API is too fragile, a=
nd SSL_MODE_SEND_FALLBACK_SCSV should be ignored in this case. So clar=
ifying that in the spec is not the *only* thing we can do to prevent this.<=
/div>

NSS API does allow =
this too.

Thing is, we want to have a way to test =
if the servers are tolerant to future clients
that claim they had=
 to downgrade. So having the ability to set TL1.2 with this
SCSV =
is useful, just like is having an easy to use, widely distributed CLI tool<=
/div>
 (openssl command) that can do this should help with testing and =
interoperability,
IMHO.


-- 
Regards,
Hubert Kario
Qu=
ality Engineer, QE BaseOS Security team
Email: hkario@redhat.com
Web:=
 www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, B=
rno, Czech Republic

------=_Part_13104896_336762867.1413553221954--


From nobody Fri Oct 17 06:44:49 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258C61ACDDA for ; Fri, 17 Oct 2014 06:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-_f19CuAvpU for ; Fri, 17 Oct 2014 06:44:45 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C988D1ACDB5 for ; Fri, 17 Oct 2014 06:44:44 -0700 (PDT)
Received: from mail-yh0-f45.google.com (mail-yh0-f45.google.com [209.85.213.45]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0McAjL-1XOxzi0WaF-00JbfG; Fri, 17 Oct 2014 15:44:41 +0200
Received: by mail-yh0-f45.google.com with SMTP id b6so364283yha.18 for ; Fri, 17 Oct 2014 06:44:39 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.22.228 with SMTP id t64mr3857494yht.164.1413553479936; Fri, 17 Oct 2014 06:44:39 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Fri, 17 Oct 2014 06:44:39 -0700 (PDT)
In-Reply-To: <5440CC7F.1020608@brainhub.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <5440CC7F.1020608@brainhub.org>
Date: Fri, 17 Oct 2014 15:44:39 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=e89a8f642a980af70505059e91cd
X-Provags-ID: V02:K0:erd3n5Hq5xZLdPjCubIK48LCXZ1HmNjaIAzbwAuTRRn zS5V4iGQZHmPtJRLxo1PknRUlV1L73uvY+2NnkSqbYyxNoVOTm vKGoy9YxFH5PczsF0/pYYJkkKJud8xqLOmIr2e9xZyowPwP8jp 4MD6Aus17kcjzMSRa4jJ1rNS3JU125y3zzubJvQsxDqo8c3BKX Gr/L5gkGjGFiqIfBLGnPR7fsaIXh88TNP7mDvzXmqEBKQktARy f+iGkGGjhaSckhbS6QnN1Ap1sQnvE++Nq47BP7pv/HoHIK2SFl /abcRX7Qpo4uvPaZxnMvYYa9Yz5eMc5/5B4yBX6GcpddCDo9ID 7doVIH+G5q3Wu3cScCmTQGs/Z1SwyqSmHlIPeKlFRDjV8nBuSz PKoJ+1CmiXRBiVy78HD/d9Kc2laY69r6sp52Fzjy3Vvya8wxzi suf7J
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0aH-ABVsWb5X0kigl4oN4Eo6ZIg
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 13:44:47 -0000

--e89a8f642a980af70505059e91cd
Content-Type: text/plain; charset=UTF-8

Andrey Jivsov :

(On handling of the downgrade to a recent versions of the protocols, i.e.
> TLS1.3 to 1.2 or TLS1.2 to TLS1.1.)
>


> The draft -00 asks the server supporting TLS 1.2 to fail the TLS 1.1 in
> some cases, while significant amount of traffic on the Internet goes over
> TLS 1.0.
>

Right. If both the client and the server *do* support TLS 1.2, we want to
ensure that they won't unnecessarily fall back to an earlier protocol
version (thus losing the benefits of TLS 1.2). If one of them only supports
an earlier protocol version, they'll still be using that one --
TLS_FALLBACK_SCSV doesn't get in the way for that.


Today, for example,

   www.wellsfargo.com, citibank.com, and bankofamerica.com don't support
> TLS 1.1 and
>    mozilla.com doesn't support TLS 1.2.


Note that this isn't the kind of downgrade that TLS_FALLBACK_SCSV is about.

All of the above sites, and indeed most TLS 1.0 sites on the internet, will
properly negotiate the supported protocol version. That is, the client can
send a Client Hello advertising support for TLS 1.2, and the server will
directly respond with a Server Hello selecting TLS 1.0 or TLS 1.1. There's
no fallback retry in which the client adjusts its advertised protocol
version, and thus no need to send TLS_FALLBACK_SCSV.

Also, even if the client *does* retry with a lower protocol version (TLS
1.1 with TLS_FALLBACK_SCSV, or eventually TLS 1.0 with TLS_FALLBACK_SCSV),
such as because the initial handshake failed due to some network glitch,
these servers would still accept the new handshakes according to the
TLS_FALLBACK_SCSV specification. The spec only requires them to reject
Client Hellos with TLS_FALLBACK_SCSV if the advertised protocol version is
*lower* than the maximum protocol version supported by the client.



> I propose the following change that allows to do exactly what rev -00
> says, but now enables more tolerant server behaviour.
>

As discussed above, I don't see any problem that this change would address.

The spec intentionally gives exact rules for server-side behavior, allowing
the *clients* to fully drive the fallback strategy and determine when it's
OK to fall back to an earlier protocol version and when it's not (with no
server-side heuristics involved).

Bodo

--e89a8f642a980af70505059e91cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Andr=
ey Jivsov <crypto@brainhub.org>:

(On handling of the downgrade to a recent versi=
ons of the protocols, i.e. TLS1.3 to 1.2 or TLS1.2 to TLS1.1.)
=C2=A0

The draft -00 asks the server supporting TLS 1.2 to fail the TLS 1.1 in som=
e cases, while significant amount of traffic on the Internet goes over TLS =
1.0.

Right. If both the client and the =
server *do* support TLS 1.2, we want to ensure that they won't unnecess=
arily fall back to an earlier protocol version (thus losing the benefits of=
 TLS 1.2). If one of them only supports an earlier protocol version, they&#=
39;ll still be using that one -- TLS_FALLBACK_SCSV doesn't get in the w=
ay for that.


Today, for examp=
le,=C2=A0
=C2=A0 =C2=A0www.wellsfargo.com,=C2=A0citibank.com, and=C2=A0bankofamerica.com=C2=
=A0don't support TLS 1.1 and
=C2=A0 =C2=A0mozilla.com=C2=A0doesn't support TLS 1.2.

Note that this isn't the kind of d=
owngrade that TLS_FALLBACK_SCSV is about.

All of t=
he above sites, and indeed most TLS 1.0 sites on the internet, will properl=
y negotiate the supported protocol version. That is, the client can send a =
Client Hello advertising support for TLS 1.2, and the server will directly =
respond with a Server Hello selecting TLS 1.0 or TLS 1.1. There's no fa=
llback retry in which the client adjusts its advertised protocol version, a=
nd thus no need to send TLS_FALLBACK_SCSV.

Also, e=
ven if the client *does* retry with a lower protocol version (TLS 1.1 with =
TLS_FALLBACK_SCSV, or eventually TLS 1.0 with TLS_FALLBACK_SCSV), such as b=
ecause the initial handshake failed due to some network glitch, these serve=
rs would still accept the new handshakes according to the TLS_FALLBACK_SCSV=
 specification. The spec only requires them to reject Client Hellos with TL=
S_FALLBACK_SCSV if the advertised protocol version is *lower* than the maxi=
mum protocol version supported by the client.

=C2=
=A0

I propose the following change that allows to do exactly what rev -00 says,=
 but now enables more tolerant server behaviour.

<=
/div>
As discussed above, I don't see any problem that this change =
would address.

The spec intentionally gives exact =
rules for server-side behavior, allowing the *clients* to fully drive the f=
allback strategy and determine when it's OK to fall back to an earlier =
protocol version and when it's not (with no server-side heuristics invo=
lved).

Bodo



--e89a8f642a980af70505059e91cd--


From nobody Fri Oct 17 06:51:19 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F81B1ACDF8 for ; Fri, 17 Oct 2014 06:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6Sv6EfLxGr2 for ; Fri, 17 Oct 2014 06:51:17 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B4B1ACDB5 for ; Fri, 17 Oct 2014 06:51:10 -0700 (PDT)
Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0LoIFV-1YKlHO2Icj-00gJp3; Fri, 17 Oct 2014 15:51:07 +0200
Received: by mail-yk0-f171.google.com with SMTP id 79so356936ykr.16 for ; Fri, 17 Oct 2014 06:51:06 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.191.230 with SMTP id g66mr11373993yhn.27.1413553866453;  Fri, 17 Oct 2014 06:51:06 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Fri, 17 Oct 2014 06:51:06 -0700 (PDT)
In-Reply-To: <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>
Date: Fri, 17 Oct 2014 15:51:06 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=20cf305b108214c3ac05059ea865
X-Provags-ID: V02:K0:l3uDUYW4M60BPV//uHom6qSLIz6OjrtxhmdJqCVOiyX t3mYX8r4ymt5QQhi2ECF3MOz6rKrJ1kP9nq12wfEv/sKKstRiO 7Vwd3j87RKrM3ymF7kelmKqzFEdo+p4MeGsWRQSJzYrJ+UenK8 2vm/SSOsQHcp80C617uYh57I3C8x3tqQMnnZgvgAiEC9fXaIq7 +slxEeHuCmJv6zckIiFx8iB81ZUbt+vfRYEICFHjZrshFjq6E4 a08sHcPEMVbMpywQF2wZcCIot5Hgy7kooG3fqRyftGf00w/LhU Tk9IfypDmyGYzgnsadEPnobfqlLwej7R38p+AmICY/WyG0/oU1 VKyoYgr8U91BsYn9VkTtE4wYpGVTq8l9FltjdVvXAKO5QNrlT+ yFbzRx6R9kI0czcdEfPLgfEdBp/HTbvPsQi9XkQH4csJDM1fEl BpXhv
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eGqT7Uz6nbFfkqQ5JagNSRocEyo
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 13:51:18 -0000

--20cf305b108214c3ac05059ea865
Content-Type: text/plain; charset=UTF-8

Hubert Kario :

> (Arguably the OpenSSL API is too fragile, and SSL_MODE_SEND_FALLBACK_SCSV
> should be ignored in this case. So clarifying that in the spec is not the
> *only* thing we can do to prevent this.
>
>

> NSS API does allow this too.
>
> Thing is, we want to have a way to test if the servers are tolerant to
> future clients
> that claim they had to downgrade. So having the ability to set TL1.2 with
> this
> SCSV is useful, just like is having an easy to use, widely distributed CLI
> tool
> (openssl command) that can do this should help with testing and
> interoperability,
> IMHO.
>

I know. This is exactly why OpenSSL does honor SSL_MODE_SEND_FALLBACK_SCSV
even when the highest supported protocol version is enabled. (So the best
way to make the API less fragile might be to create an additional setting
that makes SSL_MODE_SEND_FALLBACK_SCSV behavior unconditional, such as
SSL_MODE_SEND_FALLBACK_SCSV_FOR_TESTING.)

Bodo

--20cf305b108214c3ac05059ea865
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hube=
rt Kario <hkario@redhat.com>:
(Arguably the OpenSSL API =
is too fragile, and=C2=A0SSL_MODE_SEND_FALLBACK_SCSV should be ignored in t=
his case. So clarifying that in the spec is not the *only* thing we can do =
to prevent this.
=C2=A0
NSS API does allow this too.

T=
hing is, we want to have a way to test if the servers are tolerant to futur=
e clients
that claim they had to downgrade. So having the ability=
 to set TL1.2 with this
SCSV is useful, just like is having an ea=
sy to use, widely distributed CLI tool
 (openssl command) that ca=
n do this should help with testing and interoperability,
IMHO.

I know. This is exactly why=
 OpenSSL does honor=C2=A0SSL_MODE_SEND_FALLBACK_SCSV even when the highest =
supported protocol version is enabled. (So the best way to make the API les=
s fragile might be to create an additional setting that makes SSL_MODE_SEND=
_FALLBACK_SCSV behavior unconditional, such as SSL_MODE_SEND_FALLBACK_SCSV_=
FOR_TESTING.)

Bodo



--20cf305b108214c3ac05059ea865--


From nobody Fri Oct 17 11:04:20 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991C31A007E for ; Fri, 17 Oct 2014 11:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s5YGpwiWyZU for ; Fri, 17 Oct 2014 11:04:17 -0700 (PDT)
Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460EB1A0007 for ; Fri, 17 Oct 2014 11:04:17 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-09v.sys.comcast.net with comcast id 4J4C1p0032VvR6D01J4GfL; Fri, 17 Oct 2014 18:04:16 +0000
Received: from [IPv6:::1] ([71.202.164.227]) by resomta-ch2-19v.sys.comcast.net with comcast id 4J4F1p00J4uhcbK01J4FeA; Fri, 17 Oct 2014 18:04:16 +0000
Message-ID: <54415A1F.3080707@brainhub.org>
Date: Fri, 17 Oct 2014 11:04:15 -0700
From: Andrey Jivsov 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <5440CC7F.1020608@brainhub.org> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413569056; bh=CML0IkanPx2bY9vbW+yFF/DFmDHqSZsetvjSc+OkBmo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PHNxHAY3sJSlk8mthtRtamHiAvRB6lVf2LCTv1lvKtSMM0i0jU8vS7BtQWnhQ6EyJ dmRvCqTMFsEKcVbeEbxrvzSop9YQGaxGEE8qdktFeROOZXawUYzIhKzYCD7AFxBUjX IcoK5Volr5m/vrjmCMT3c1Qk1JZ9r0phtCvlW/Al0TDIkvH4KO5v0TLRKsZe42EUzj jh/IS7N5pUYjqddVKRJXnI0VafoJRkyT45TWgVtjITuiBwWhMXAgzL/1YRluPev7cz Bzt9RaHHe2/oqsKSTzxNFF4HVvfhTF6nty91xL+m+L5hEYfmwcedd1ivoBBxYml6iJ HU+teTg5lT8cg==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MST-koHTL5ow87X7idgFXqDxLjE
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 18:04:19 -0000

On 10/17/2014 06:44 AM, Bodo Moeller wrote:
> Andrey Jivsov >:
>
>     (On handling of the downgrade to a recent versions of the
>     protocols, i.e. TLS1.3 to 1.2 or TLS1.2 to TLS1.1.)
>
>     The draft -00 asks the server supporting TLS 1.2 to fail the TLS
>     1.1 in some cases, while significant amount of traffic on the
>     Internet goes over TLS 1.0.
>
>
> Right. If both the client and the server *do* support TLS 1.2, we want 
> to ensure that they won't unnecessarily fall back to an earlier 
> protocol version (thus losing the benefits of TLS 1.2). If one of them 
> only supports an earlier protocol version, they'll still be using that 
> one -- TLS_FALLBACK_SCSV doesn't get in the way for that.

Yes, but note that the draft requires servers to fail on TLS 1.1 when 
they were not required to do so before.

This is on the backdrop that the downgrade issue is entirely due to some 
client-specific implementation of the protocol negotiation (the 
fallback) and client's view that TLS 1.1 is secure (as a matter of fact, 
they would currently talk SSL3.0 without any warning).

>
>
>     Today, for example, 
>
>     www.wellsfargo.com , citibank.com
>     , and bankofamerica.com
>      don't support TLS 1.1 and
>     mozilla.com  doesn't support TLS 1.2.
>
>
> Note that this isn't the kind of downgrade that TLS_FALLBACK_SCSV is 
> about.
>
> All of the above sites, and indeed most TLS 1.0 sites on the internet, 
> will properly negotiate the supported protocol version. That is, the 
> client can send a Client Hello advertising support for TLS 1.2, and 
> the server will directly respond with a Server Hello selecting TLS 1.0 
> or TLS 1.1. There's no fallback retry in which the client adjusts its 
> advertised protocol version, and thus no need to send TLS_FALLBACK_SCSV.

The reality of the Internet today is that TLS 1.1 is viewed as 
acceptable. Clients treating TLS 1.1 treating it this way too. The draft 
*requires* to introduce a rejection of TLS 1.1 connection on the server 
when the server detects the downgrade.

My point is that downgrades from TLS1.0 to SSL3.0 is one thing but from 
TLS1.3 to TLS1.2 is another.

>
> Also, even if the client *does* retry with a lower protocol version 
> (TLS 1.1 with TLS_FALLBACK_SCSV, or eventually TLS 1.0 with 
> TLS_FALLBACK_SCSV), such as because the initial handshake failed due 
> to some network glitch, these servers would still accept the new 
> handshakes according to the TLS_FALLBACK_SCSV specification. The spec 
> only requires them to reject Client Hellos with TLS_FALLBACK_SCSV if 
> the advertised protocol version is *lower* than the maximum protocol 
> version supported by the client.

If the server supports TLS1.2 and the server sees TLS1.1+SCSV, the 
server MUST fail with inappropriate_fallback. Isn't this is what section 
3 says?

>
>     I propose the following change that allows to do exactly what rev
>     -00 says, but now enables more tolerant server behaviour.
>
>
> As discussed above, I don't see any problem that this change would 
> address.
>
> The spec intentionally gives exact rules for server-side behavior, 
> allowing the *clients* to fully drive the fallback strategy and 
> determine when it's OK to fall back to an earlier protocol version and 
> when it's not (with no server-side heuristics involved).

Servers are often independent nodes on the Internet. Servers may have 
their own policy regarding when it's appropriate to reject a connection 
and, in general, what are the security implications of the version 
downgrade is.

Today, latest popular browsers will happily connect to a SSL3.0 server 
without any indication to a user.

>
> Bodo
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Fri Oct 17 13:03:34 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2AA1A0164 for ; Fri, 17 Oct 2014 13:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kku9-TeAoYTY for ; Fri, 17 Oct 2014 13:03:25 -0700 (PDT)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2721A003B for ; Fri, 17 Oct 2014 13:03:25 -0700 (PDT)
Received: by mail-la0-f54.google.com with SMTP id gm9so1306555lab.13 for ; Fri, 17 Oct 2014 13:03:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DV7jue0Y1HO92+kExlFI/gZ75E0myF4ENYc7qD4Dyd4=; b=JvPt+8pBJlY1oO+sUS68Av8qDBCeD0EYhecCbjVkIph8LlVmmJpNlcK/vCda8VIVbP syNSNlm9ZDDQGH+HwPy9DKlXMKfHFgGWNCAQANnkIg5qhFO5m4krfq/gGWkLUNPKTk8Y DrQT5iDZS6rVebw3S2atTDCrV6VmcN8tz+piWWdEvk28Icxhjd18p9N/d6t8eez86poD etrCwavcKlcYgy/oKLHsi8NhYJi8jYCY5HeUR2g/hQ4+oXTLo9H4jhuKZsdojsqg6p9P 4kMLL6u8Y92Nzsc0UQ/2Y3nCCtECsaz6YKU9zZ91+d9zcC8He2KgOmGWZuAuQwotO7mN fVyA==
MIME-Version: 1.0
X-Received: by 10.152.216.200 with SMTP id os8mr5554962lac.85.1413576203824; Fri, 17 Oct 2014 13:03:23 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Fri, 17 Oct 2014 13:03:23 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com> 
Date: Fri, 17 Oct 2014 13:03:23 -0700
Message-ID: 
From: Martin Thomson 
To: Bodo Moeller 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zGhUiVHdD0A-JBGrtYYH_RvvUt8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 20:03:32 -0000

On 17 October 2014 06:51, Bodo Moeller  wrote:
> I know. This is exactly why OpenSSL does honor SSL_MODE_SEND_FALLBACK_SCSV
> even when the highest supported protocol version is enabled. (So the best
> way to make the API less fragile might be to create an additional setting
> that makes SSL_MODE_SEND_FALLBACK_SCSV behavior unconditional, such as
> SSL_MODE_SEND_FALLBACK_SCSV_FOR_TESTING.)

I considered building this sort of feature, but it comes down to this:
if you are doing the fallback thing, such that setting this option is
even a possibility, then you are already tall enough to work out when
to send the SCSV and when not to.

Furthermore, we have situations where clients are configured to send
less than the highest version initially, such that it would not be
appropriate to set the SCSV.  And, we now have experimental TLS 1.3
code in NSS, all of which makes the question of  what the actual
highest version that is supported quite murky.

Another alternative is to have a value that is set to the highest
version permitted.  Handshakes that go out with lower version numbers
get marked with the SCSV.  Set this to a low value and the SCSV is
suppressed.


From nobody Fri Oct 17 13:35:33 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAEB1A6EDA for ; Fri, 17 Oct 2014 13:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnQ0Trmx1yF0 for ; Fri, 17 Oct 2014 13:35:29 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::765]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF011A1B5D for ; Fri, 17 Oct 2014 13:35:29 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 17 Oct 2014 20:35:05 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Fri, 17 Oct 2014 20:35:05 +0000
From: Andrei Popov 
To: Martin Thomson , Bodo Moeller 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: AQHP6g/vkqpMmvBKoUCxL3G2jHnzlpw0TqsAgABoBICAAAgfwA==
Date: Fri, 17 Oct 2014 20:35:05 +0000
Message-ID: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB418;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0367A50BB1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(377454003)(13464003)(24454002)(85306004)(86362001)(31966008)(50986999)(76176999)(54356999)(101416001)(92566001)(20776003)(108616004)(64706001)(4396001)(122556002)(40100003)(33646002)(15975445006)(93886004)(230783001)(86612001)(2656002)(87936001)(95666004)(99286002)(105586002)(85852003)(120916001)(99396003)(97736003)(74316001)(21056001)(76576001)(19580405001)(19580395003)(46102003)(80022003)(106356001)(107046002)(76482002)(106116001)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XT7aXuMsWGUV93SIAJjlpk42Cgg
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 20:35:32 -0000

Now that SSL's days are counted, why use SCSV (rather than a TLS extension)=
?

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Friday, October 17, 2014 1:03 PM
To: Bodo Moeller
Cc: tls@ietf.org
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group =
Last Call for draft-ietf-tls-downgrade-scsv-00)

On 17 October 2014 06:51, Bodo Moeller  wrote:
> I know. This is exactly why OpenSSL does honor=20
> SSL_MODE_SEND_FALLBACK_SCSV even when the highest supported protocol=20
> version is enabled. (So the best way to make the API less fragile=20
> might be to create an additional setting that makes=20
> SSL_MODE_SEND_FALLBACK_SCSV behavior unconditional, such as
> SSL_MODE_SEND_FALLBACK_SCSV_FOR_TESTING.)

I considered building this sort of feature, but it comes down to this:
if you are doing the fallback thing, such that setting this option is even =
a possibility, then you are already tall enough to work out when to send th=
e SCSV and when not to.

Furthermore, we have situations where clients are configured to send less t=
han the highest version initially, such that it would not be appropriate to=
 set the SCSV.  And, we now have experimental TLS 1.3 code in NSS, all of w=
hich makes the question of  what the actual highest version that is support=
ed quite murky.

Another alternative is to have a value that is set to the highest version p=
ermitted.  Handshakes that go out with lower version numbers get marked wit=
h the SCSV.  Set this to a low value and the SCSV is suppressed.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From nobody Fri Oct 17 14:03:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C684A1A7012 for ; Fri, 17 Oct 2014 14:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbyoIZ0cWHXZ for ; Fri, 17 Oct 2014 14:03:05 -0700 (PDT)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8B21A7000 for ; Fri, 17 Oct 2014 14:03:05 -0700 (PDT)
Received: by mail-lb0-f182.google.com with SMTP id z11so1297322lbi.41 for ; Fri, 17 Oct 2014 14:03:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RuI2RzI1ycUXvSU/xI6gTB3iy1yv52vY04oi7gT2jpk=; b=jGKUUg+nafXrZOBfJyLqZPIv+AVzo/CoKweKO4Vf6EkL9nun+50WbFMRNrxkApA6NS pdJIYfJ3KYcPJURATXBMO0fD0EguL7DLnhJ40oIhbWp63sHE9gOaSzmuEBaFgH2LIv+q BOVHkMHI/QfPQ0jE4wDtBfuYznrFSnpxiIOaNJXBZ3z0xqdjj2MOPBmoYMePJc/bfs6I CJa2YVw9PUeeqkAk/VYArqiaNdft1N9YhfbDW5fWGLYFlkfRL8sDpzzFY1P7ojmpi6U5 tT4PaDI7bHLtfpnF8vGxHSN3SKq85VxwUwmIq+Qor071cytpEB9fxcQxYEdSRs9zJbZ2 BiYg==
MIME-Version: 1.0
X-Received: by 10.112.169.66 with SMTP id ac2mr11377886lbc.73.1413579783448; Fri, 17 Oct 2014 14:03:03 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Fri, 17 Oct 2014 14:03:03 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>   
Date: Fri, 17 Oct 2014 14:03:03 -0700
Message-ID: 
From: Martin Thomson 
To: Andrei Popov 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ICrvq3BsCk-iya0dxCcQudiV3po
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 21:03:07 -0000

On 17 October 2014 13:35, Andrei Popov  wrote:
> Now that SSL's days are counted, why use SCSV (rather than a TLS extension)?

I wasn't going to ask that question now that it's been implemented and
deployed, but I do have to wonder if that's not the right thing to do
here...


From nobody Fri Oct 17 14:14:54 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E431A0102 for ; Fri, 17 Oct 2014 14:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKvT0cTLbZSp for ; Fri, 17 Oct 2014 14:14:50 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495BC1A19EC for ; Fri, 17 Oct 2014 14:14:50 -0700 (PDT)
Received: by mail-ig0-f169.google.com with SMTP id uq10so3551917igb.2 for ; Fri, 17 Oct 2014 14:14:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gDF66NC6S63iQrIj8qxGLK5X2Z6k6dPxLm17XvH2u5s=; b=mQFSBCM3aAeGo02qCSOFcLJILDax2uLIYTJFHDcW2B6uCfkDNy1pgiXIyCUj8pGFb4 /lR1DlhPXHCe+jJG+riGRcWzrHQ6DsnXnr7sbmOZwF6f9KLbo+NNlJIblzw+6c26bTmQ PcLWF+6kLci1J7zGWqthLxgvIycvKcVtE8HZhDfgD8KsbbQCatjTordX1QuffVU5skyk 7XgtKbdK5LczlKmYNDkiAX3Aw5AoX4jsEmju854ALZQiWnzzKOsDE0crjUZ58O/HHb+c Yl9HQNTCo8ZuWqWaXWU9nWF26l5PqJuwGj05VwpWo+uboj0IDt2T18xEgpYSd09GCm86 HMlQ==
MIME-Version: 1.0
X-Received: by 10.42.21.19 with SMTP id i19mr12586777icb.37.1413580489784; Fri, 17 Oct 2014 14:14:49 -0700 (PDT)
Received: by 10.107.3.87 with HTTP; Fri, 17 Oct 2014 14:14:49 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>    
Date: Fri, 17 Oct 2014 17:14:49 -0400
Message-ID: 
From: Jeffrey Walton 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/R7HVlwoQaQzHq8ihQpSrpopq0zg
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 21:14:51 -0000

On Fri, Oct 17, 2014 at 5:03 PM, Martin Thomson
 wrote:
> On 17 October 2014 13:35, Andrei Popov  wrote:
>> Now that SSL's days are counted, why use SCSV (rather than a TLS extension)?
>
> I wasn't going to ask that question now that it's been implemented and
> deployed, but I do have to wonder if that's not the right thing to do
> here...
>
+1

Related: "Why do browsers probe and fallback (or, why
SSL_MODE_SEND_FALLBACK_SCSV)?",
http://security.stackexchange.com/q/70988.


From nobody Fri Oct 17 14:37:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FB61A8546 for ; Fri, 17 Oct 2014 14:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-XGgnMQT66Z for ; Fri, 17 Oct 2014 14:37:32 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::771]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACAA81A702A for ; Fri, 17 Oct 2014 14:37:32 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB417.namprd03.prod.outlook.com (10.141.92.12) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 17 Oct 2014 21:37:09 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Fri, 17 Oct 2014 21:37:09 +0000
From: Andrei Popov 
To: Martin Thomson 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: AQHP6g/vkqpMmvBKoUCxL3G2jHnzlpw0TqsAgABoBICAAAgfwIAACI2AgAAH2aA=
Date: Fri, 17 Oct 2014 21:37:09 +0000
Message-ID: <7fe248e5b4374fbd8d04ff460bc3ace8@BL2PR03MB419.namprd03.prod.outlook.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com>	<543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB417;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0367A50BB1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(24454002)(13464003)(189002)(33646002)(46102003)(99396003)(85852003)(74316001)(86362001)(50986999)(93886004)(97736003)(21056001)(110136001)(101416001)(80022003)(85306004)(92566001)(76176999)(108616004)(54356999)(120916001)(86612001)(19580405001)(19580395003)(106116001)(4396001)(105586002)(76576001)(230783001)(31966008)(122556002)(20776003)(106356001)(76482002)(64706001)(99286002)(87936001)(107046002)(40100003)(2656002)(95666004)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3QKNvKxLMMbeUoMazsA4PReQgJM
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 21:37:36 -0000

SXQncyBub3QgYW4gUkZDIHlldCwgc28gcGVyaGFwcyB3ZSBzaG91bGQgYXQgbGVhc3QgY29uc2lk
ZXIgdXNpbmcgYSBUTFMgZXh0ZW5zaW9uLiBTQ1NWcyBhcmUgdWdseSBoYWNrcy4gQSBzaW1wbGUg
VExTIGV4dGVuc2lvbiBpcyBwcm9iYWJseSBub3QgbXVjaCBoYXJkZXIgdG8gaW1wbGVtZW50IHRo
YW4gYW4gU0NTViwgYW5kIG1heSByZXN1bHQgaW4gY2xlYW5lciBjb2RlLg0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhv
bXNvbkBnbWFpbC5jb21dIA0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDE3LCAyMDE0IDI6MDMgUE0N
ClRvOiBBbmRyZWkgUG9wb3YNCkNjOiBCb2RvIE1vZWxsZXI7IHRsc0BpZXRmLm9yZw0KU3ViamVj
dDogUmU6IFtUTFNdIFRoZSBUTFNfRkFMTEJBQ0tfU0NTViB0aW1lIGJvbWIgKHdhczogUmU6IFdv
cmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLXRscy1kb3duZ3JhZGUtc2Nzdi0w
MCkNCg0KT24gMTcgT2N0b2JlciAyMDE0IDEzOjM1LCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3Bv
dkBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4gTm93IHRoYXQgU1NMJ3MgZGF5cyBhcmUgY291bnRl
ZCwgd2h5IHVzZSBTQ1NWIChyYXRoZXIgdGhhbiBhIFRMUyBleHRlbnNpb24pPw0KDQpJIHdhc24n
dCBnb2luZyB0byBhc2sgdGhhdCBxdWVzdGlvbiBub3cgdGhhdCBpdCdzIGJlZW4gaW1wbGVtZW50
ZWQgYW5kIGRlcGxveWVkLCBidXQgSSBkbyBoYXZlIHRvIHdvbmRlciBpZiB0aGF0J3Mgbm90IHRo
ZSByaWdodCB0aGluZyB0byBkbyBoZXJlLi4uDQo=


From nobody Fri Oct 17 15:29:02 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5462D1A1BB9 for ; Fri, 17 Oct 2014 15:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLzzZOp4_rKW for ; Fri, 17 Oct 2014 15:28:58 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0ABC1A1BAC for ; Fri, 17 Oct 2014 15:28:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413584937; x=1445120937; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=zEMzOnOoaQvYXnCWaQvGLf7JW/SfozeaKqD0PoVSbf4=; b=gDwO88yCdhqLZ8rozJiZQsnyXo/zayQfTyCEf9qSgYRitXdKlfzMRTvu SFTvLURNVr1mwvM9pM4iO2MUZS9/r6MwTO4eQieyzcAMCklgeacW/Yhsc lMotxTQmDo/gi1z1uuhNguT1N4w1XQjnz2gV4WrsTkc0xq7aYljSLlEe6 A=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="283981604"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 18 Oct 2014 11:28:51 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sat, 18 Oct 2014 11:28:51 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: Ac/qWbnb0ukEClldTMybjpT0HzlhrA==
Date: Fri, 17 Oct 2014 22:28:50 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D1333@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2avZh9lUCCQ0SHWryTQKR7kiRwA
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 22:29:02 -0000

Andrei Popov  writes:=0A=
=0A=
>Now that SSL's days are counted, why use SCSV (rather than a TLS extension=
)?=0A=
=0A=
Counted to what?  Five thousand?  Ten thousand?  That's still a long time t=
o=0A=
go.=0A=
=0A=
Peter.=


From nobody Fri Oct 17 15:35:04 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B9D1A7D84 for ; Fri, 17 Oct 2014 15:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvJkRnrLT5bH for ; Fri, 17 Oct 2014 15:34:59 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:765]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3252A1A1BC8 for ; Fri, 17 Oct 2014 15:34:59 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 17 Oct 2014 22:34:36 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Fri, 17 Oct 2014 22:34:36 +0000
From: Andrei Popov 
To: Peter Gutmann , "" 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: Ac/qWbnbkqpMmvBKoUCxL3G2jHnzlgAAFCDg
Date: Fri, 17 Oct 2014 22:34:36 +0000
Message-ID: <1cc9c2d4409d4bf6b69a1ee21ef188d8@BL2PR03MB419.namprd03.prod.outlook.com>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D1333@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9D1333@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB418;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0367A50BB1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(377454003)(13464003)(86362001)(85306004)(31966008)(54356999)(50986999)(76176999)(101416001)(92566001)(20776003)(108616004)(64706001)(4396001)(122556002)(40100003)(15975445006)(33646002)(230783001)(86612001)(2656002)(87936001)(95666004)(99286002)(105586002)(85852003)(120916001)(99396003)(97736003)(74316001)(76576001)(21056001)(19580405001)(46102003)(80022003)(106356001)(107046002)(76482002)(107886001)(19580395003)(3826002)(24736002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/niydlo6VNVcreqf9RvfLJr8gR-4
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 22:35:03 -0000

I think about 60-90 days or so, for those clients and servers that get regu=
lar updates.
=20
-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Peter Gutmann
Sent: Friday, October 17, 2014 3:29 PM
To: 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group =
Last Call for draft-ietf-tls-downgrade-scsv-00)

Andrei Popov  writes:

>Now that SSL's days are counted, why use SCSV (rather than a TLS extension=
)?

Counted to what?  Five thousand?  Ten thousand?  That's still a long time t=
o go.

Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From nobody Fri Oct 17 16:49:33 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421941A87B1 for ; Fri, 17 Oct 2014 16:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB9pCV7WnNG8 for ; Fri, 17 Oct 2014 16:49:30 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::762]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1018C1A879E for ; Fri, 17 Oct 2014 16:49:29 -0700 (PDT)
Received: from BY2PR03MB427.namprd03.prod.outlook.com (10.141.141.146) by BY2PR03MB159.namprd03.prod.outlook.com (10.242.36.18) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Fri, 17 Oct 2014 23:49:06 +0000
Received: from BY2PR03MB554.namprd03.prod.outlook.com (10.141.141.156) by BY2PR03MB427.namprd03.prod.outlook.com (10.141.141.146) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Fri, 17 Oct 2014 23:49:05 +0000
Received: from BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) by BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) with mapi id 15.00.1049.012; Fri, 17 Oct 2014 23:49:05 +0000
From: Marsh Ray 
To: Andrei Popov , Martin Thomson 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: AQHP6g/w1BhRgIoKW0S6M5mRt7fur5w0TqsAgABoBICAAAjbgIAAB9GAgAAJh4CAACPrIA==
Date: Fri, 17 Oct 2014 23:49:05 +0000
Message-ID: <76533ab02b644597a170cb5b76a42a99@BY2PR03MB554.namprd03.prod.outlook.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com>	<543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>     <7fe248e5b4374fbd8d04ff460bc3ace8@BL2PR03MB419.namprd03.prod.outlook.com>
In-Reply-To: <7fe248e5b4374fbd8d04ff460bc3ace8@BL2PR03MB419.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ee31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB427;UriScan:;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0367A50BB1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(108616004)(122556002)(19580405001)(106356001)(40100003)(92566001)(120916001)(105586002)(74316001)(64706001)(54356999)(31966008)(4396001)(20776003)(50986999)(107046002)(110100005)(76176999)(87936001)(1511001)(76576001)(230783001)(2656002)(2421001)(93886004)(97736003)(95666004)(46102003)(86612001)(86362001)(101416001)(99286002)(76482002)(99396003)(106116001)(21056001)(19580395003)(85852003)(85306004)(33646002)(80022003)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB427; H:BY2PR03MB554.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB159;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ge_KfvR2TfeoQmhD_ICiPAyo35E
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 23:49:32 -0000

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Andrei Popov
> It's not an RFC yet, so perhaps we should at least consider using
> a TLS extension. SCSVs are ugly hacks. A simple TLS
> extension is probably not much harder to implement than
> an SCSV, and may result in cleaner code.

At least I think I remember hearing somewhere that
"SSLv3 without extensions" is one of the configurations that some
of these auto-downgrading client applications fall back to.

- Marsh


From nobody Fri Oct 17 16:54:55 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C831A87C1 for ; Fri, 17 Oct 2014 16:54:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXD_9Q9aRRzZ for ; Fri, 17 Oct 2014 16:54:50 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::717]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344531A87C3 for ; Fri, 17 Oct 2014 16:54:50 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB548.namprd03.prod.outlook.com (10.141.91.140) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 17 Oct 2014 23:54:27 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Fri, 17 Oct 2014 23:54:27 +0000
From: Andrei Popov 
To: Marsh Ray , Martin Thomson 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: AQHP6g/vkqpMmvBKoUCxL3G2jHnzlpw0TqsAgABoBICAAAgfwIAACI2AgAAH2aCAACaKgIAAAF8g
Date: Fri, 17 Oct 2014 23:54:27 +0000
Message-ID: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com>	<543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>     <7fe248e5b4374fbd8d04ff460bc3ace8@BL2PR03MB419.namprd03.prod.outlook.com> <76533ab02b644597a170cb5b76a42a99@BY2PR03MB554.namprd03.prod.outlook.com>
In-Reply-To: <76533ab02b644597a170cb5b76a42a99@BY2PR03MB554.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB548;
x-forefront-prvs: 0367A50BB1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(199003)(377454003)(97736003)(99396003)(2421001)(120916001)(76482002)(31966008)(50986999)(76576001)(21056001)(76176999)(54356999)(87936001)(230783001)(93886004)(85306004)(122556002)(2656002)(108616004)(74316001)(40100003)(85852003)(33646002)(64706001)(19580395003)(19580405001)(20776003)(80022003)(46102003)(86612001)(86362001)(92566001)(4396001)(106356001)(107046002)(1511001)(106116001)(95666004)(101416001)(99286002)(105586002)(110100005)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB548; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Q4BnfCaHb-bGvZ77OTGrvn5aulk
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 23:54:53 -0000

Correct; however thanks to POODLE, these auto-downgrading client applicatio=
ns are rapidly removing SSL3 from the fallback sequence. So the reason for =
having SCSV (instead of a proper TLS extension) is disappearing.

-----Original Message-----
From: Marsh Ray=20
Sent: Friday, October 17, 2014 4:49 PM
To: Andrei Popov; Martin Thomson
Cc: tls@ietf.org
Subject: RE: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group =
Last Call for draft-ietf-tls-downgrade-scsv-00)

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Andrei Popov
> It's not an RFC yet, so perhaps we should at least consider using a=20
> TLS extension. SCSVs are ugly hacks. A simple TLS extension is=20
> probably not much harder to implement than an SCSV, and may result in=20
> cleaner code.

At least I think I remember hearing somewhere that
"SSLv3 without extensions" is one of the configurations that some of these =
auto-downgrading client applications fall back to.

- Marsh


From nobody Fri Oct 17 17:16:31 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6B01A8853 for ; Fri, 17 Oct 2014 17:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRFCDJlRkGaz for ; Fri, 17 Oct 2014 17:16:28 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D441A884F for ; Fri, 17 Oct 2014 17:16:27 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id mc6so1523669lab.30 for ; Fri, 17 Oct 2014 17:16:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3qT1W16ltAFtz/eYzXKLLFMJZ440XhNSCVvRbyZHSxQ=; b=XwsHIRX39ad+AzSrGHONeSUuJTV4bTvmV+Xja1Cgr5M8Dt+gKh4869KKMOr6Y67Efx Sfwy2M+Rk11VnOxVLsHyfmaS+HjCSxDFaF1qWq542TSPEN4N7cL7U+iI2op2TiGigzjd 8vhQSSzPMLsq+mTxRVUXcFa18GpFJQbi5hatgjmfOctYwi4nxHBWLFIGiLKCeCiCZl4k x1Q3TWcO4bScOysv81Kgye4vzhpDLQI8L0qMpRJvOxTLqf82yGPxXeonP3XPCIH7W9MW pYs1nm4CBEPXxNmG1l2e6SFLyPshO6lphtnx5syyWOtnu0H0hYRfEQzzKWmR68ZR7R2K OuNw==
MIME-Version: 1.0
X-Received: by 10.152.28.134 with SMTP id b6mr12458314lah.12.1413591386021; Fri, 17 Oct 2014 17:16:26 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Fri, 17 Oct 2014 17:16:25 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>     <7fe248e5b4374fbd8d04ff460bc3ace8@BL2PR03MB419.namprd03.prod.outlook.com> <76533ab02b644597a170cb5b76a42a99@BY2PR03MB554.namprd03.prod.outlook.com> 
Date: Fri, 17 Oct 2014 17:16:25 -0700
Message-ID: 
From: Martin Thomson 
To: Andrei Popov 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ht9cU6taVgImCZGXUdAgGVqUhYo
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 00:16:29 -0000

On 17 October 2014 16:54, Andrei Popov  wrote:
> Correct; however thanks to POODLE, these auto-downgrading client applications are rapidly removing SSL3 from the fallback sequence. So the reason for having SCSV (instead of a proper TLS extension) is disappearing.

I think on balance it's worth leaving this.  I expect NSS will
maintain SSLv3 for some time to come for various reasons that I don't
like, but am willing to tolerate.  The SCSV is going to provide a
measure of protection to those people who are forced to allow it to
live.


From nobody Fri Oct 17 18:08:41 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C151A00E4 for ; Fri, 17 Oct 2014 18:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZa61U816rb2 for ; Fri, 17 Oct 2014 18:08:23 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3DCD1A0087 for ; Fri, 17 Oct 2014 18:08:22 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB548.namprd03.prod.outlook.com (10.141.91.140) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Sat, 18 Oct 2014 01:08:21 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Sat, 18 Oct 2014 01:08:21 +0000
From: Andrei Popov 
To: Martin Thomson 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: AQHP6g/vkqpMmvBKoUCxL3G2jHnzlpw0TqsAgABoBICAAAgfwIAACI2AgAAH2aCAACaKgIAAAF8ggAAHRICAAAleYA==
Date: Sat, 18 Oct 2014 01:08:20 +0000
Message-ID: <8f805ba832b645e680bb5aba5b878265@BL2PR03MB419.namprd03.prod.outlook.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com>	<543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>     <7fe248e5b4374fbd8d04ff460bc3ace8@BL2PR03MB419.namprd03.prod.outlook.com> <76533ab02b644597a170cb5b76a42a99@BY2PR03MB554.namprd03.prod.outlook.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB548;
x-forefront-prvs: 0368E78B5B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(199003)(377454003)(189002)(86612001)(92566001)(86362001)(4396001)(19580405001)(64706001)(19580395003)(46102003)(20776003)(80022003)(95666004)(106116001)(107046002)(105586002)(99286002)(110100005)(101416001)(106356001)(76482002)(31966008)(21056001)(54356999)(76176999)(50986999)(76576001)(99396003)(97736003)(120916001)(40100003)(85852003)(33646002)(110136001)(122556002)(85306004)(93886004)(2656002)(87936001)(230783001)(108616004)(74316001)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB548; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Sxjd_IxDG1NYz8rNb3B0eUe-l00
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 01:08:32 -0000

Q2VydGFpbmx5IGEgbG90IG9mIGltcGxlbWVudGF0aW9ucyB3aWxsIGtlZXAgU1NMMyBjb2RlIGFy
b3VuZCBmb3IgYSB3aGlsZSwganVzdCBkaXNhYmxlZCBieSBkZWZhdWx0Lg0KDQpPbiB0aGUgY2xp
ZW50IHNpZGUsIFNDU1YgKG5vdCBleHRlbnNpb24pIGlzIG9ubHkgbmVlZGVkIGlmIGZhbGxiYWNr
IHRvIFNTTDMgaXMgYWxsb3dlZCwgY29ycmVjdD8gVGhpcyBpcyB0aGUgdmVyeSBmYWxsYmFjayB0
aGF0IGJyb3dzZXIgdmVuZG9ycyBhcmUgZGlzYWJsaW5nIHJpZ2h0IG5vdy4gU28gdGhlIG9ubHkg
YnJvd3NlcnMgdGhhdCBmYWxsIGJhY2sgdG8gU1NMMyB3aWxsIGJlIHRoZSBvbmVzIHdpdGhvdXQg
dGhlIERvd25ncmFkZS1TQ1NWIHN1cHBvcnQuDQoNCk9uIHRoZSBzZXJ2ZXIgc2lkZSwgU0NTViAo
bm90IGV4dGVuc2lvbikgaXMgb25seSBuZWVkZWQgaWYgYSkgU1NMMyBpcyBlbmFibGVkLCBhbmQg
YikgdGhlIHNlcnZlciB0cmllcyB0byBwcm90ZWN0IGNsaWVudHMgdGhhdCBvZmZlciBUTFMxLjAg
KG5vdCAxLjEgb3IgMS4yKSBhdCB0aGUgZmlyc3QgY29ubmVjdGlvbiBhdHRlbXB0LiBBbSBJIG1p
c3Npbmcgc29tZXRoaW5nPyBIb3dldmVyLCBhIGJyb3dzZXIgdGhhdCBpbXBsZW1lbnRzIGEgc2hp
bnkgbmV3IERvd25ncmFkZS1zb21ldGhpbmcgUkZDIGlzIHVubGlrZWx5IHRvIG9mZmVyIFRMUzEu
MCBvbiB0aGUgZmlyc3QgY29ubmVjdGlvbiBhdHRlbXB0Lg0KDQpUaGlzIGlzIHdoeSBJIHRoaW5r
IHRoZSBjYXNlIGZvciBTQ1NWIG5vdCBleHRlbnNpb24gaXMgdmVyeSB3ZWFrLCBhbmQgZ2V0dGlu
ZyB3ZWFrZXIgYnkgdGhlIGRheS4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21z
b25AZ21haWwuY29tXSANClNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNywgMjAxNCA1OjE2IFBNDQpU
bzogQW5kcmVpIFBvcG92DQpDYzogTWFyc2ggUmF5OyB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl
OiBbVExTXSBUaGUgVExTX0ZBTExCQUNLX1NDU1YgdGltZSBib21iICh3YXM6IFJlOiBXb3JraW5n
IEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi10bHMtZG93bmdyYWRlLXNjc3YtMDApDQoN
Ck9uIDE3IE9jdG9iZXIgMjAxNCAxNjo1NCwgQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWlj
cm9zb2Z0LmNvbT4gd3JvdGU6DQo+IENvcnJlY3Q7IGhvd2V2ZXIgdGhhbmtzIHRvIFBPT0RMRSwg
dGhlc2UgYXV0by1kb3duZ3JhZGluZyBjbGllbnQgYXBwbGljYXRpb25zIGFyZSByYXBpZGx5IHJl
bW92aW5nIFNTTDMgZnJvbSB0aGUgZmFsbGJhY2sgc2VxdWVuY2UuIFNvIHRoZSByZWFzb24gZm9y
IGhhdmluZyBTQ1NWIChpbnN0ZWFkIG9mIGEgcHJvcGVyIFRMUyBleHRlbnNpb24pIGlzIGRpc2Fw
cGVhcmluZy4NCg0KSSB0aGluayBvbiBiYWxhbmNlIGl0J3Mgd29ydGggbGVhdmluZyB0aGlzLiAg
SSBleHBlY3QgTlNTIHdpbGwgbWFpbnRhaW4gU1NMdjMgZm9yIHNvbWUgdGltZSB0byBjb21lIGZv
ciB2YXJpb3VzIHJlYXNvbnMgdGhhdCBJIGRvbid0IGxpa2UsIGJ1dCBhbSB3aWxsaW5nIHRvIHRv
bGVyYXRlLiAgVGhlIFNDU1YgaXMgZ29pbmcgdG8gcHJvdmlkZSBhIG1lYXN1cmUgb2YgcHJvdGVj
dGlvbiB0byB0aG9zZSBwZW9wbGUgd2hvIGFyZSBmb3JjZWQgdG8gYWxsb3cgaXQgdG8gbGl2ZS4N
Cg==


From SRS0=E8DF=7J=acm.org=bmoeller@srs.kundenserver.de  Sat Oct 18 04:56:29 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55D21A6FE4 for ; Sat, 18 Oct 2014 04:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRChhJRwSevh for ; Sat, 18 Oct 2014 04:56:28 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1A01A6FE2 for ; Sat, 18 Oct 2014 04:56:28 -0700 (PDT)
Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0LrbET-1Y9XYC4AKD-013NMN; Sat, 18 Oct 2014 13:56:26 +0200
Received: by mail-yk0-f171.google.com with SMTP id 79so1009205ykr.2 for ; Sat, 18 Oct 2014 04:56:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.191.230 with SMTP id g66mr20357269yhn.27.1413633383765;  Sat, 18 Oct 2014 04:56:23 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Sat, 18 Oct 2014 04:56:23 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>   
Date: Sat, 18 Oct 2014 13:56:23 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=20cf305b1082ae9c480505b12bba
X-Provags-ID: V02:K0:p7KfZWCRWKu1l4hAw1rU0Pdz92/D7Nm81F5eyBZOmiS FFaCXxRu/9W0AtGqFJzjy91oKSPOigMGicJDjxR0yMMe/guf6O uNGTUbtoElueicEYKKfR8kpHYTfTy47qf/Y+263U7vr4IzSmYZ ImZWeS4O8KTfik/JqcZhzP3EnjIxgAjhzzRmqlc5fh4fVBo7Uc oqAwP9wfHysNQnwQ3eHiINKj0dFEGS1tHtfzUNyDKjwDn/u9LU QvgRmRrkcA+YJ1bNns8goG2E4OTDFGHe9DcaOaJIC7zl6lqVqH n7JXmSyVxOo1o4lFXLVcwYGGWVHCrqIw7KObjzpnsb17b9hoUc uZYEbvPTAGUMcXbiTcf4bSY62DvpZbDXYeqg4hcna2CNoucTUV eKcDwJHVHlxwNAHZSt/quWWYqlLmCiimqUmlxvO6ZBK0PeGJk/ TtEXh
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zQlWAjeGyZkC7Uvn7VfFBjmNQd8
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 11:57:05 -0000

--20cf305b1082ae9c480505b12bba
Content-Type: text/plain; charset=UTF-8

Andrei Popov :

> Now that SSL's days are counted, why use SCSV (rather than a TLS
> extension)?


Even once we no longer need to worry about extension *intolerant* servers,
we still should take into account that extension *support* remains optional
for TLS servers. Servers can legitimately ignore ClientServer.extensions
entirely. Having a fallback_indication TLS extension would be overly
onerous for such servers: they'd need to implement extension parsing just
to be able to find this one signal. Looking for the SCSV is much simpler.

(Also, there's less overhead in sending an SCSV vs. sending an empty
extension.)

Also, of course, it will be a while until we know whether the premise of
your question is even true. I certainly hope so, but users that might need
to enable a fallback to SSL 3.0 for whatever reason still deserve the best
possible protection from attacks.

Bodo

--20cf305b1082ae9c480505b12bba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Andr=
ei Popov <Andrei.Popov@microsoft.com>:
Now that SSL's days are counted, why use SCSV (rather than a TL=
S extension)?
=C2=A0
Even once we no longer need=
 to worry about extension *intolerant* servers, we still should take into a=
ccount that extension *support* remains optional for TLS servers. Servers c=
an legitimately ignore ClientServer.extensions entirely. Having a fallback_=
indication TLS extension would be overly onerous for such servers: they'=
;d need to implement extension parsing just to be able to find this one sig=
nal. Looking for the SCSV is much simpler.

(Also, =
there's less overhead in sending an SCSV vs. sending an empty extension=
.)

Also, of course, it will be a while until we kn=
ow whether the premise of your question is even true. I certainly hope so, =
but users that might need to enable a fallback to SSL 3.0 for whatever reas=
on still deserve the best possible protection from attacks.

<=
/div>
Bodo



--20cf305b1082ae9c480505b12bba--


From nobody Sat Oct 18 05:09:05 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7986F1A6FEE for ; Sat, 18 Oct 2014 05:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYOXhh02bJtZ for ; Sat, 18 Oct 2014 05:08:59 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4F11A6FE4 for ; Sat, 18 Oct 2014 05:08:59 -0700 (PDT)
Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0ML7th-1Xfjvl3KW9-000OyZ; Sat, 18 Oct 2014 14:08:57 +0200
Received: by mail-yh0-f54.google.com with SMTP id z6so1064303yhz.13 for ; Sat, 18 Oct 2014 05:08:54 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.228.161 with SMTP id f31mr20353572yhq.51.1413634134501;  Sat, 18 Oct 2014 05:08:54 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Sat, 18 Oct 2014 05:08:54 -0700 (PDT)
In-Reply-To: <54415A1F.3080707@brainhub.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <5440CC7F.1020608@brainhub.org>  <54415A1F.3080707@brainhub.org>
Date: Sat, 18 Oct 2014 14:08:54 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113335266df1c90505b158c3
X-Provags-ID: V02:K0:yPSMtTzvrbLWFvhu9nDucInzK0SHEB5IwAAQZCxHIDC MA5cQR69RB7r957L1XIu4BCMDSzH9C2hIr27+s9Olj1SqSCJPh Z2aHsC0c6dtX2/1v7seIoZnW3lHZdScdpxKBM6YxVsiYdwi15w Z6F21okrcJx8wBkWhcL8HibYfyTtf0e4zdCFc4wuiUSz04BMzL AYzarFfvjbJUOZE4Y2q95F28czo8l91E/PWhW+JbQxzFY5yPti 6vIXNXS/ZjhaEYJiRGGYRVCzX99yHN43eSL850rSgrHH8wPcNb DtnPQLlJGhEWGBELDlRSB2mdkC4R0LiWdJ717oGYBXpzLKZ/fw recHl7eP1WFiVIahQyOfZstzTXDTaIgoXbDNBrmJrYYM3mHnli yi6lbk1FSMPG9IngeHNFWDXchCuldeLjbjAGi8go2cld2sMg4Y kgCa/
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e_9vj3VWfQ86Owe23Yy44fL-vN4
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 12:09:00 -0000

--001a113335266df1c90505b158c3
Content-Type: text/plain; charset=UTF-8

Andrey Jivsov :

The reality of the Internet today is that TLS 1.1 is viewed as acceptable.
> Clients treating TLS 1.1 treating it this way too. The draft *requires* to
> introduce a rejection of TLS 1.1 connection on the server when the server
> detects the downgrade.
>

According to the draft, this server-side rejection is REQUIRED *if the
client sent TLS_FALLBACK_SCSV to request it*. For the client, however, it
is merely RECOMMENDED to send TLS_FALLBACK_SCSV in all fallback retries.

My point is that downgrades from TLS1.0 to SSL3.0 is one thing but from
> TLS1.3 to TLS1.2 is another.


You appear to be saying that, carefully weighing the case, a silent
fallback to TLS 1.2 can be acceptable. I don't disagree: the spec takes
this into account, it's just that it leaves it to the *client* to make this
decision, without further *server*-side heuristics interfering with it,.

(I think this makes sense because it's the client that decides whether to
do fallback retries in the first place. For clients that don't set
TLS_FALLBACK_SCSV at all, for example, any server-side enabled protocol
version can be negotiated anyway -- the server can't avoid using old
versions with such clients other than by disabling them entirely.)

Bodo

--001a113335266df1c90505b158c3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Andr=
ey Jivsov <crypto@brainhub.org>:


The reality of the Internet today is that TLS 1.1 is viewed as acceptable. =
Clients treating TLS 1.1 treating it this way too. The draft *requires* to =
introduce a rejection of TLS 1.1 connection on the server when the server d=
etects the downgrade.

According to the =
draft, this server-side rejection is REQUIRED *if the client sent TLS_FALLB=
ACK_SCSV to request it*. For the client, however, it is merely RECOMMENDED =
to send TLS_FALLBACK_SCSV in all fallback retries.


My point is that downgrades from TLS1.0 to SSL3.0 is one thing but from TLS=
1.3 to TLS1.2 is another.

You appear to be =
saying that, carefully weighing the case, a silent fallback to TLS 1.2 can =
be acceptable. I don't disagree: the spec takes this into account, it&#=
39;s just that it leaves it to the *client* to make this decision, without =
further *server*-side heuristics interfering with it,.

=

(I think this makes sense because it's the client that decides whe=
ther to do fallback retries in the first place. For clients that don't =
set TLS_FALLBACK_SCSV at all, for example, any server-side enabled protocol=
 version can be negotiated anyway -- the server can't avoid using old v=
ersions with such clients other than by disabling them entirely.)

Bodo



--001a113335266df1c90505b158c3--


From nobody Sat Oct 18 07:33:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AE91A888D for ; Sat, 18 Oct 2014 07:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.078
X-Spam-Level: 
X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puSQz5u3GVhJ for ; Sat, 18 Oct 2014 07:33:02 -0700 (PDT)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCC11A888B for ; Sat, 18 Oct 2014 07:33:02 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id d1so3234956wiv.12 for ; Sat, 18 Oct 2014 07:33:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=SxCV7d5sulDvZcdepCcOgTTq55n61CIUxhcUnbhuJig=; b=DEmrCTyk//7+DWJFFrgwSN0qjJgoLLVV2FmkziblSz2/As6pLmIO53iwwKYlF2ZkXO iNvpaGSDZGK5blC7YJrKc6921WCwDLxDIpRN+Om6cOFraIHdPb3WiZE/vlTZsKahoUr5 aZK3tjXhnhPMtvxUViktINKiFr2B1xLEkvPfWVZh5EaP9RFbX1RQAe/cdiSH3pEMAZm4 JMVDXnsszK2Z5J1J3U+fLkjIlDAsuldW29Lsscisb0ATc5S4BFGAo4Y5ivo4HWox58xo U/CxlqjaCvsJDxUwsMYk61H3bVdhRU7bMUlUebpToMPdrb/BJtNF+ccMe+5wgjj3QpBb ybIQ==
X-Gm-Message-State: ALoCoQkB0LZhCAga31Q/ajdzSuL8p2ngxTkxNtkKReocbZKxotY5e70GMx4HNMX2MqM0BGfqLyKD
X-Received: by 10.180.103.233 with SMTP id fz9mr6319510wib.80.1413642780931; Sat, 18 Oct 2014 07:33:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Sat, 18 Oct 2014 07:32:20 -0700 (PDT)
From: Eric Rescorla 
Date: Sat, 18 Oct 2014 15:32:20 +0100
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=f46d044280cacc36dd0505b35b09
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UI3PSESGqUM-MVDr0VlBnr8YAFs
Subject: [TLS] Refactoring client auth/re-key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 14:33:06 -0000

--f46d044280cacc36dd0505b35b09
Content-Type: text/plain; charset=UTF-8

Folks,

What follows is a drafty proposal for tackling a number of different
desiderata for 1.3 while also simplifying much of the protocol
analysis. The following integrates a bunch of separate discussions
starting with the YYZ interim and ideas from Adam Langley, Alfredo
Pironti, Andrei Popov, Martin Thomson and others.

The idea here is to unify:

 1. Session hash.
 2. Key refresh (based on MT's proposal from YYZ)
 3. Client authentication

As background, the current handshake looks like this.

       ClientHello
       ClientKeyShare            -------->
                                                       ServerHello
                                                    ServerKeyShare
                                                [ChangeCipherSpec]
                                              EncryptedExtensions*
                                                      Certificate*
                                               CertificateRequest*
                                                CertificateVerify*
                                 <--------                Finished
       [ChangeCipherSpec]
       Certificate*
       CertificateVerify*
       Finished                  -------->


Now that we are adopting session-hash, we want to use it for TLS 1.3
as well, but a straight adaptation is inconvenient because:

1.  We have moved encryption up so we need to generate the keys
    before we have either cert, but we then can't incorporate
    them into the session hash.

2.  We want the server to be able to send data in his first flight
    if he doesn't care about client auth.

In addition, there are a couple of other pieces of which would be nice:

3.  Be able to add client auth at any part of the handshake.

4.  Be able to regenerate the traffic keys now that we have
    removed renegotiation.

These last two are the major purposes served by renegotiation.


We could try to address each of these individually, but taking a look
at this, it seems like we could solve a number of these problems
together by pulling client auth out of the main handshake and into a
followon protocol (see below). This would leave us with a single,
uniform, handshake whether client auth is being used or not.


       ClientHello
       ClientKeyShare            -------->
                                                       ServerHello
                                                    ServerKeyShare  <-- A
                                              EncryptedExtensions*
                                                      Certificate*
                                                CertificateVerify*
                                 <--------                Finished  <-- B
       Finished                  -------->

This would integrate with session-hash as follows:

- At point A we would generate one set of keys based on the MS and the
  transcript so far. Those keys would be used to encipher the rest of
  the handshake.

- At point B we would generate a new set of keys based on the MS and
  the transcript so far. Those keys would be used to encipher the
  traffic and the Finished messages. [0]


REKEY
Of course, we now need to have rekeying and client auth. I propose to
merge those into a single mechanism called Update. For simplicity,
let's consider Update without client auth first.

  enum { rekey(1), ack(2),  authentication(3), (255) } UpdateType;
  struct {
    UpdateType update_type;

    switch (update_type) {
      case rekey:
        Random random;

      case ack:
        opaque digest<0..255>;  /* Based on the PRF */

      ...
    }
  } Update;

In order to force a re-key, an implementation sends an Update message
with a random nonce. It then digests the existing traffic keys in the
sending direction with the Update contents (see below). The other side
must respond with an UpdateAck which includes a digest of the Update
message, computed using the PRF and similarly digests its update
message with its sending keys. The result is that the sending keys in
both directions now depend on the entire sequence of Update messages
that have been sent.



KEY SCHEDULE
There are a lot of different things we could do for the key schedule
but it's useful to have a concrete proposal, so consider the following.

Currently TLS has a single Master Secret which is used to compute
directional traffic keys. Instead, we should have two unidirectional
MSs, each initially generated from the initial PMS. E.g.,

      master_secret_client = PRF(pre_master_secret, "master secret_client",
                                 ClientHello.random + ServerHello.random)
                                 [0..47];

      master_secret_server = PRF(pre_master_secret, "master secret_server",
                                 ClientHello.random + ServerHello.random)
                                 [0..47];

Every time an Update is sent by element X, we recompute master_secret_X,
as follows:

      master_secret_X_{i+1} = PRF(master_secret_X_i, "master_secret_update",
                                  Update_message)

We then recompute the traffic keys based on the current master secret. This
produces the following pattern in each direction:

                       X           Y
                       |           |
                       v           v

      PMS -->    MS_0 --->  MS_1 ---> MS_2 --->  ...
                  |          |         |
                  v          v         v
               Traffic    Traffic   Traffic
                Keys 0     Keys 1    Keys 1

As should be clear, once MS_{i+1} has been computed from MS_{i} we can
discard MS_{i}. This provides a form of protection for the previous traffic,
since if you compromise either side at (for instance) the point labelled Y,
then it's not possible to decrypt traffic sent at X, since you would need
MS_0 or TK_0, but these can have been discarded at this point, and since
the PRF is nominally one-way, you can't compute MS_{i} from MS_{i+1}. [1]


SIMULTANEOUS UPDATE
It's obviously possible that both sides will try to update at once.
That shouldn't be a problem here since the order of the Updates and hence
key changes is deterministic on both sides. For example:


           Client                                   Server
[C_MS_0]                                                     [S_MS_0]
           Update (A) ------------------------>
[C_MS_1]
                      <------------------------  Update (B)
                                                             [S_MS_1]
                      <------------------------     ACK (C)
                                                             [S_MS_2]
           ACK (D)    ------------------------>
[C_MS_2]


The key computations are as follows:

C_MS_1 = PRF(C_MS_0, A)
S_MS_1 = PRF(S_MS_0, B)
C_MS_2 = PRF(C_MS_1, D) [D depends only on B]
S_MS_2 = PRF(S_MS_1, C) [C depends only on A, but S_MS_2 depends
                         on S_MS_1 which depends on B].

Note: the above needs double-checking since I haven't coded it up and
it's possible there's some way to get confused. The important property
we are trying to have is that we don't need to worry about which of
two messages that cross in flight was sent first.


CLIENT AUTH
We can easily extend this mechanism to allow client auth (as well as
adding keys to the server, I suppose) by allowing the Update message
to contain a Certificate and CertificateVerify. I.e.,

  enum { rekey(1), ack(2),  authentication(3), (255) } UpdateType;
  struct {
    UpdateType update_type;

    switch (update_type) {
      case rekey:
        Random random;

      case ack:
        opaque digest<0..255>;  /* Based on the PRF */

      case authentication:
        Certificate certificate;
        CertificateVerify verify;
    }
  } Update;

Note: it might be nice to always have the Random value.

One open issue is what the CertificateVerify should cover. Probably
what's most convenient is to maintain a running hash of the initial
transcript plus every Update that has been sent in the forward
direction. Note that we don't want to include Updates sent in the
reverse direction, since that would create race conditions where
it's not clear if a CertificateVerify from the client covers
an Update sent at approximately the same time from the server.

Note that this causes the simultaneous update (above) to result in
S_MS_2 to depend on Update(B).  Though B is part of a different update
exchange, it appears before C in the transcript (and they are sent by
the same side) and is therefore covered by the hash used in the
certificate verify

Important note: I've removed CertificateRequest entirely. As Andrei
Popov has pointed out, it's (a) complicated and (b) insufficiently
flexible. The idea here is to push this up to the application layer
where we can be more expressive and avoid the clunky CR syntax we have
now. It is also obviously possible for the client to unilaterally
offer client auth or the server to unilaterally add a new server
certificate [This last may be regarded as a bug or a feature.]

-Ekr

[0] One could also imagine using the original keys to encipher
the Finished message, or generating yet more keys. When Alfredo
and I discussed this, he didn't think this affected the proof, so
I've proposed the simplest option.

[1] Note that this doesn't address the question of resumption. If we
retain resumption, we need to keep a secret which can be used for
resumption. It's easy to make it distinct from the C_MS_0 and C_MS_1
generated in the full handshake by generating a third independent
resumption secret R_MS from the initial PMS. This would be used for
resumed connections; obviously this means that if you recover R_MS
you can attack all the resumed connections but not the original
connecn. We could probably invent some techniques for keeping
those connections, but it's hard to do without keeping state on
the server.

--f46d044280cacc36dd0505b35b09
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Folks,

What follows is a dra=
fty proposal for tackling a number of different
desiderata for 1.=
3 while also simplifying much of the protocol
analysis. The follo=
wing integrates a bunch of separate discussions
starting with the=
 YYZ interim and ideas from Adam Langley, Alfredo
Pironti, Andrei=
 Popov, Martin Thomson and others.

The idea here i=
s to unify:

=C2=A01. Session hash.
=C2=
=A02. Key refresh (based on MT's proposal from YYZ)
=C2=A03. =
Client authentication

As background, the current h=
andshake looks like this.

=C2=A0 =C2=A0 =C2=A0 =C2=
=A0ClientHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0ClientKeyShare =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ServerHello
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 ServerKeyShare
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ChangeCipherSp=
ec]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 EncryptedExtensions*
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate*
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Certif=
icateRequest*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CertificateVerify*
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<-------- =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Finished
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0[ChangeCipherSpec]
=C2=A0 =C2=A0 =C2=A0 =C2=A0Certifica=
te*
=C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateVerify*
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0Finished =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0-------->


No=
w that we are adopting session-hash, we want to use it for TLS 1.3
as well, but a straight adaptation is inconvenient because:
1.=C2=A0 We have moved encryption up so we need to generate the=
 keys
=C2=A0 =C2=A0 before we have either cert, but we then can&#=
39;t incorporate
=C2=A0 =C2=A0 them into the session hash.
<=
div>
2.=C2=A0 We want the server to be able to send data in h=
is first flight
=C2=A0 =C2=A0 if he doesn't care about client=
 auth.

In addition, there are a couple of other pi=
eces of which would be nice:

3.=C2=A0 Be able to a=
dd client auth at any part of the handshake.

4.=C2=
=A0 Be able to regenerate the traffic keys now that we have
=C2=
=A0 =C2=A0 removed renegotiation.

These last two a=
re the major purposes served by renegotiation.

We could try to address each of these individually, but taking =
a look
at this, it seems like we could solve a number of these pr=
oblems
together by pulling client auth out of the main handshake =
and into a
followon protocol (see below). This would leave us wit=
h a single,
uniform, handshake whether client auth is being used =
or not.


=C2=A0 =C2=A0 =C2=A0 =C2=A0=
ClientHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0ClientKeyShare =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0ServerHello
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 ServerKeyShare =C2=A0<-- A
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 EncryptedExt=
ensions*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 CertificateVerify*
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0<-------- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Finished =C2=A0<-- B
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0Finished =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0-------->

This would integrate with session-=
hash as follows:

- At point A we would generate on=
e set of keys based on the MS and the
=C2=A0 transcript so far. T=
hose keys would be used to encipher the rest of
=C2=A0 the handsh=
ake.

- At point B we would generate a new set of k=
eys based on the MS and
=C2=A0 the transcript so far. Those keys =
would be used to encipher the
=C2=A0 traffic and the Finished mes=
sages. [0]


REKEY
Of cours=
e, we now need to have rekeying and client auth. I propose to
mer=
ge those into a single mechanism called Update. For simplicity,
l=
et's consider Update without client auth first.

=C2=A0 enum { rekey(1), ack(2), =C2=A0authentication(3), (255) } UpdateTy=
pe;
=C2=A0 struct {
=C2=A0 =C2=A0 UpdateType update_typ=
e;
=C2=A0=C2=A0
=C2=A0 =C2=A0 switch (update_type) {
=C2=A0 =C2=A0 =C2=A0 case rekey:
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 Random random;

=C2=A0 =C2=A0 =C2=A0 case ack:<=
/div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque digest<0..255>; =C2=A0/*=
 Based on the PRF */
=C2=A0
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 }
=C2=A0 } Update;

In order to force a re-key, an implementation sends an Update message
with a random nonce. It then digests the existing traffic keys in the=

sending direction with the Update contents (see below). The othe=
r side
must respond with an UpdateAck which includes a digest of =
the Update
message, computed using the PRF and similarly digests =
its update
message with its sending keys. The result is that the =
sending keys in
both directions now depend on the entire sequence=
 of Update messages
that have been sent.



KEY SCHEDULE
There are a lot of di=
fferent things we could do for the key schedule
but it's usef=
ul to have a concrete proposal, so consider the following.

Currently TLS has a single Master Secret which is used to compute<=
/div>
directional traffic keys. Instead, we should have two unidirectio=
nal
MSs, each initially generated from the initial PMS. E.g.,

=C2=A0 =C2=A0 =C2=A0 master_secret_client =3D PRF(pre=
_master_secret, "master secret_client",
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ClientHello.random + ServerHello.random)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[0..47];

=

=C2=A0 =C2=A0 =C2=A0 master_secret_server =3D PRF(pre_master_sec=
ret, "master secret_server",
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0ClientHello.random + ServerHello.random)
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[0..47];

=
Every time an Update is sent by element X, we recompute master_secret_X,
as follows:

=C2=A0 =C2=A0 =C2=A0 master_se=
cret_X_{i+1} =3D PRF(master_secret_X_i, "master_secret_update",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Update_message)
<=
div>
We then recompute the traffic keys based on the current =
master secret. This
produces the following pattern in each direct=
ion:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0X =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
Y
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0v =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 PMS --> =C2=A0 =
=C2=A0MS_0 ---> =C2=A0MS_1 ---> MS_2 ---> =C2=A0...
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0v =C2=A0 =C2=A0 =C2=A0 =C2=A0 v
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Traffic =C2=A0 =C2=A0Traffic =C2=A0 T=
raffic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ke=
ys 0 =C2=A0 =C2=A0 Keys 1 =C2=A0 =C2=A0Keys 1

As s=
hould be clear, once MS_{i+1} has been computed from MS_{i} we can
discard MS_{i}. This provides a form of protection for the previous traff=
ic,
since if you compromise either side at (for instance) the poi=
nt labelled Y,
then it's not possible to decrypt traffic sent=
 at X, since you would need
MS_0 or TK_0, but these can have been=
 discarded at this point, and since
the PRF is nominally one-way,=
 you can't compute MS_{i} from MS_{i+1}. [1]

<=
br>
SIMULTANEOUS UPDATE
It's obviously possible tha=
t both sides will try to update at once.
That shouldn't be a =
problem here since the order of the Updates and hence
key changes=
 is deterministic on both sides. For example:


=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server
[C_MS_0] =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 [S_MS_0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Update (A) ------------------------>
[C_MS_1] =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <------------------------ =C2=A0Update (B)
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[S_MS_1]
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <------------------------ =C2=A0 =C2=A0 ACK (C)
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[S_MS_2]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ACK (D) =C2=A0 =C2=A0----------=
-------------->
[C_MS_2]
=C2=A0 =C2=A0 =C2=A0 =C2=A0=


The key computations are as follows:
C_MS_1 =3D PRF(C_MS_0, A)
S_MS_1 =3D PRF(S_MS_0, B)<=
/div>
C_MS_2 =3D PRF(C_MS_1, D) [D depends only on B]
S_MS_2 =
=3D PRF(S_MS_1, C) [C depends only on A, but S_MS_2 depends
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0on S_MS_1 which depends on B].

Note: =
the above needs double-checking since I haven't coded it up and
it's possible there's some way to get confused. The important pr=
operty
we are trying to have is that we don't need to worry a=
bout which of
two messages that cross in flight was sent first.


CLIENT AUTH
We can easily =
extend this mechanism to allow client auth (as well as
adding key=
s to the server, I suppose) by allowing the Update message
to con=
tain a Certificate and CertificateVerify. I.e.,

=
=C2=A0 enum { rekey(1), ack(2), =C2=A0authentication(3), (255) } UpdateType=
;
=C2=A0 struct {
=C2=A0 =C2=A0 UpdateType update_type;=

=C2=A0=C2=A0
=C2=A0 =C2=A0 switch (update_type) {
=C2=A0 =C2=A0 =C2=A0 case rekey:
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 Random random;

=C2=A0 =C2=A0 =C2=A0 case ack:<=
/div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque digest<0..255>; =C2=A0/*=
 Based on the PRF */
=C2=A0
=C2=A0 =C2=A0 =C2=A0 case a=
uthentication:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate certificat=
e;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 CertificateVerify verify;
=C2=A0 =C2=A0 }
=C2=A0 } Update;

Note:=
 it might be nice to always have the Random value.

One open issue is what the CertificateVerify should cover. Probably
<=
div>what's most convenient is to maintain a running hash of the initial=

transcript plus every Update that has been sent in the forward
direction. Note that we don't want to include Updates sent in =
the
reverse direction, since that would create race conditions wh=
ere
it's not clear if a CertificateVerify from the client cov=
ers
an Update sent at approximately the same time from the server=
.

Note that this causes the simultaneous update (a=
bove) to result in
S_MS_2 to depend on Update(B).=C2=A0 Though B =
is part of a different update
exchange, it appears before C in th=
e transcript (and they are sent by
the same side) and is therefor=
e covered by the hash used in the
certificate verify
Important note: I've removed CertificateRequest entirely. =
As Andrei
Popov has pointed out, it's (a) complicated and (b)=
 insufficiently
flexible. The idea here is to push this up to the=
 application layer
where we can be more expressive and avoid the =
clunky CR syntax we have
now. It is also obviously possible for t=
he client to unilaterally
offer client auth or the server to unil=
aterally add a new server
certificate [This last may be regarded =
as a bug or a feature.]

-Ekr

<=
div>[0] One could also imagine using the original keys to encipher
the Finished message, or generating yet more keys. When Alfredo
and I discussed this, he didn't think this affected the proof, so
I've proposed the simplest option.

[1] N=
ote that this doesn't address the question of resumption. If we
retain resumption, we need to keep a secret which can be used for
<=
div>resumption. It's easy to make it distinct from the C_MS_0 and C_MS_=
1
generated in the full handshake by generating a third independe=
nt
resumption secret R_MS from the initial PMS. This would be use=
d for
resumed connections; obviously this means that if you recov=
er R_MS
you can attack all the resumed connections but not the or=
iginal
connecn. We could probably invent some techniques for keep=
ing
those connections, but it's hard to do without keeping st=
ate on
the server.



--f46d044280cacc36dd0505b35b09--


From nobody Sat Oct 18 08:15:29 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D28D1A88AF for ; Sat, 18 Oct 2014 08:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYpWnXArHvZY for ; Sat, 18 Oct 2014 08:15:25 -0700 (PDT)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A281A88A1 for ; Sat, 18 Oct 2014 08:15:20 -0700 (PDT)
Received: by mail-yk0-f170.google.com with SMTP id 20so1094702yks.1 for ; Sat, 18 Oct 2014 08:15:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WQ1JVjRTpOjf4EMP8olZC3AJlE/Mk0Y568gi5NF4BRM=; b=Bpw3P3kt0x5CldA0WXMm4n12LxIWvC46z65OJg1oUc9ekHq94Qup6YPaaXGqw6SHIm JbNFuEVysBwmgOw+mKz28qaTetxlCsf5SH6EZUMt2ExWHi41ptngAut0oriOpunnF3Qu +4iRO/0/cECGa+ih0eyaqHERqytMFdzbUzaTjjumqjCKan9jy8I6DBi7AXrPnMO9a3xK 7OkgiLb8c4OfZVqkmwNbeyg5dQpOdRwl7ucmC9DlUVmLwkUh0T4Ob3L/uBqDsKgCB/Tz mjGS2YP9yni0KTaqTL7J0WmNoDo2h2zlrOxsFoYlhvYwZ1M47iWkCuzHiuEu+VA9XYpj NJ1g==
MIME-Version: 1.0
X-Received: by 10.236.61.6 with SMTP id v6mr21738187yhc.44.1413645320051; Sat, 18 Oct 2014 08:15:20 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Sat, 18 Oct 2014 08:15:19 -0700 (PDT)
In-Reply-To: 
References: 
Date: Sat, 18 Oct 2014 08:15:19 -0700
Message-ID: 
From: Watson Ladd 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2kxA0IG4G9q6vCkYPsvJoYKHVf4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Refactoring client auth/re-key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 15:15:27 -0000

On Sat, Oct 18, 2014 at 7:32 AM, Eric Rescorla  wrote:
>
So I seem to remember DJB telling me that once you have a properly
made channel via Diffie-Hellman, that authenticating requires just
signing a value derived from the key. (Sadly I forgot/don't know the
proof, so someone will have to check this or tell me I'm completely
wrong) So we don't need the session hash to include the certificates,
and so don't need to keep the running hash going past the first
exchange.

Concretely the idea would be as follows: A sends to B g^x, and B
responds with g^y. Both calculate MS=H(g^xy, g^x, g^y). (Of course, we
need to hash the actual messages.)

At this point we can compute channel_AtoB_key=PRF(MS, "channel AtoB
key"),  channel_BtoA_key=PRF(MS, "channel BtoA key"),
A_authstr=PRF(MS, "A authstr"), B_authstr=PRF(MS, "B authstr"). The
channel keys can be used to encrypt each side as in the proposal, and
the authstrs can be signed and sent over the channel to provide a
proof of identity. Furthermore, we could extract a channel binding in
an analogous manner, or application level keys in the same way, or a
resumption key in the same way.

Because we run the rest of the exchange over an encrypted,
authenticated channel, message manipulation isn't as much of an issue,
so the updates don't need to include the hashes they do above.

This seems to me to remove a lot of complexity in your proposal,
without affecting security. It also gets closer to generic security:
any authentication mechanism that uses a fresh value can use
A_authstr. Any means of providing a secure channel with a shared
string can use the keys, etc.

Sincerely,
Watson Ladd


From nobody Sat Oct 18 09:11:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EDA1A19E9 for ; Sat, 18 Oct 2014 09:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUVTvlE4xzM8 for ; Sat, 18 Oct 2014 09:11:41 -0700 (PDT)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A6F1A19E4 for ; Sat, 18 Oct 2014 09:11:41 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id n3so3315449wiv.15 for ; Sat, 18 Oct 2014 09:11:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uhFBRahZvxe8X32G9jEZXqqEdcWr739HBOFBvoxf7ew=; b=QSiF/oUyg/lupNt+ER9AWjHZaB+6EtHfWejELaxgLN2iQ6vm87T7P45OQtet0SsR41 MkPEbrCe2bM9mXZs0UXcH0oc3h1kTiLO1xqLqqJy/PhqZwOB2dTowMDssXLHnkpnw80T acD1yPX9+RlCtOuBFN1ZhTTBlhImoY1XB4ERzO/0vb0P0DnVFo1xJEygCTGgViVvjc62 cJcZPNqTCeNPLvb5NZVSHIt73/kOVLqJEM+NUiaIcbaw9086DQjkoRON/74Hss+paTtW 92a8rujjKkOo8o+UuI+tnH1DYbn7jk/nb5TgKBwOlLXMdaNHC7HKGeReruK6SfUsv2Ka mpqQ==
X-Gm-Message-State: ALoCoQlEbEc0ZXud56+SJkAZdkmjY/y+o6285R9lE7GBY032SW99zWdbWO76cvyX8CsW/4Wg80Wt
X-Received: by 10.194.200.36 with SMTP id jp4mr4225454wjc.114.1413648700140; Sat, 18 Oct 2014 09:11:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Sat, 18 Oct 2014 09:10:59 -0700 (PDT)
In-Reply-To: 
References:  
From: Eric Rescorla 
Date: Sat, 18 Oct 2014 17:10:59 +0100
Message-ID: 
To: Watson Ladd 
Content-Type: multipart/alternative; boundary=047d7b8743f69c24560505b4bc95
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eppfLOBIOAEGfzJ65BOd-M3WCus
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Refactoring client auth/re-key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 16:11:43 -0000

--047d7b8743f69c24560505b4bc95
Content-Type: text/plain; charset=UTF-8

Watson,

Thanks for your comments.

On Sat, Oct 18, 2014 at 4:15 PM, Watson Ladd  wrote:

> On Sat, Oct 18, 2014 at 7:32 AM, Eric Rescorla  wrote:
> >
> So I seem to remember DJB telling me that once you have a properly
> made channel via Diffie-Hellman, that authenticating requires just
> signing a value derived from the key. (Sadly I forgot/don't know the
> proof, so someone will have to check this or tell me I'm completely
> wrong) So we don't need the session hash to include the certificates,
> and so don't need to keep the running hash going past the first
> exchange.
>
> Concretely the idea would be as follows: A sends to B g^x, and B
> responds with g^y. Both calculate MS=H(g^xy, g^x, g^y). (Of course, we
> need to hash the actual messages.)
>
> At this point we can compute channel_AtoB_key=PRF(MS, "channel AtoB
> key"),  channel_BtoA_key=PRF(MS, "channel BtoA key"),
> A_authstr=PRF(MS, "A authstr"), B_authstr=PRF(MS, "B authstr"). The
> channel keys can be used to encrypt each side as in the proposal, and
> the authstrs can be signed and sent over the channel to provide a
> proof of identity.



Trying to think through this a bit, is this a generic comment on the
session-hash proposal even for TLS 1.2 where they are careful to
sign everything up to CertificateVerify? See:

https://tools.ietf.org/html/draft-ietf-tls-session-hash-02#section-4.1

Perhaps one of the authors of that document can weigh in here.

Best,
-Ekr

--047d7b8743f69c24560505b4bc95
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Watson,

Thanks for your comments.
=


On Sat, Oct =
18, 2014 at 4:15 PM, Watson Ladd <watsonbladd@gmail.com>=
 wrote:
On Sat, Oct 18, 2014 at 7:32 AM, Eric Rescorla =
<ekr@rtfm.com> wrote:

>

So I seem to remember DJB telling me that once you have a properly

made channel via Diffie-Hellman, that authenticating requires just

signing a value derived from the key. (Sadly I forgot/don't know the
proof, so someone will have to check this or tell me I'm completely

wrong) So we don't need the session hash to include the certificates,
and so don't need to keep the running hash going past the first

exchange.



Concretely the idea would be as follows: A sends to B g^x, and B

responds with g^y. Both calculate MS=3DH(g^xy, g^x, g^y). (Of course, we
need to hash the actual messages.)



At this point we can compute channel_AtoB_key=3DPRF(MS, "channel AtoB<=
br>
key"),=C2=A0 channel_BtoA_key=3DPRF(MS, "channel BtoA key"),=


A_authstr=3DPRF(MS, "A authstr"), B_authstr=3DPRF(MS, "B aut=
hstr"). The

channel keys can be used to encrypt each side as in the proposal, and

the authstrs can be signed and sent over the channel to provide a

proof of identity.


Trying to=
 think through this a bit, is this a generic comment on the
sessi=
on-hash proposal even for TLS 1.2 where they are careful to
sign =
everything up to CertificateVerify? See:


Perhaps one of the authors of that document c=
an weigh in here.

Best,
-Ekr





--047d7b8743f69c24560505b4bc95--


From nobody Sat Oct 18 09:17:14 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD5A1A19FD for ; Sat, 18 Oct 2014 09:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp-qZhI4a0fc for ; Sat, 18 Oct 2014 09:17:09 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CF31A19E9 for ; Sat, 18 Oct 2014 09:17:09 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id y10so2739321wgg.27 for ; Sat, 18 Oct 2014 09:17:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=shFjR86MfoINM0sVIv+quJ037eFPg3eO+oIYinyVYoA=; b=kM1OuLuh5ZOz1MB1iY3I3jwo96FDxNu/kVBS7eI1NIsrCydZU40Gt8xC+NW0eoe9C1 Xlyq0+Bil/Kl5ZZqAyC3E7EVPnvsR7myXTjLb0Rne6/qVLWUtNmZVjOqaAWdU13AUFIy kWHTs9SKzxw9u4LvSecxqEGtWBisWvdlLbtuYLr1yxkXLpJAC9szMtewOt4UK0Af9VyD mgnjWWSJn/gUTHLVzZU9O27uJNVmgff7ZLZGH5HN195xZq4BIz4vHqgkZhdQiRZjyV+Y DKeXTCDcFT+DXoul7lKnjqvWXn0HNEo/O10Lftph+XlyHZmz1S4gCI5qHUqNBrCexjL6 96SQ==
X-Gm-Message-State: ALoCoQkFTSPchc8G6iinu+oYM91bRBbf4M8bHU9xguIZ0OW7NV2eAnrCCuJ0LbVu/o+Iu7Ja2laG
X-Received: by 10.180.206.173 with SMTP id lp13mr5851162wic.78.1413649027771;  Sat, 18 Oct 2014 09:17:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Sat, 18 Oct 2014 09:16:27 -0700 (PDT)
From: Eric Rescorla 
Date: Sat, 18 Oct 2014 17:16:27 +0100
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c38c7c2360d10505b4d067
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oT2npNeY7R1OKokLsW-q8-T-buw
Subject: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 16:17:12 -0000

--001a11c38c7c2360d10505b4d067
Content-Type: text/plain; charset=UTF-8

Folks,

I wanted to get the discussion going on whether we need resumption [0] or
not
for TLS 1.3. This may be a quick discussion as I suspect the answer is
yes, but I figure we should decide it rather than just assuming it.


The argument for resumption seems pretty straightforward: it requires
significantly less computation (in the form of asymmetric operations)
than a full handshake. I suspect that this argument is less powerful
than it used to be for two reasons:

- Increased computational power.
- Faster algorithms in the form of ECC.

Nevertheless, we still have constrained devices, both in the form of
low-power phones and IOT-type devices. OTOH, it's not clear to me
how many of those devices actually (a) do public key cryptography
as opposed to PSK and (b) do session resumption.


Conversely, resumption adds complexity to the protocol both since you
have to implement both the full and resumed state machines and because
the client has uncertainty about whether a server will accept
resumption.

Another problem with resumption is that it is a threat to PFS.  In the
current TLS resumption design, if a session is resumable, then both
the client and the server retain the MS in their session caches [1].
Thus, even if you use a PFS cipher suite and destroy the traffic keys
and the asymmetric keys after the connection is over, an attacker who
attacks the session cache can decrypt your connection. As noted in my
previous message, it's not too difficult to separate the MS stored in
the session cache from the MS used for the initial connection that
initiated the session, but it's much harder to do so between multiple
resumptions of the same session, though perhaps we could do figure out
how to do so [2].

I'm hoping to get people's opinions on this (and we can discuss more
next week). How important is resumption to you as a performance
optimization? Is it still important when you can do all-ECC (which
it seems likely we will require clients to do for TLS 1.3).

-Ekr


[0] For purposes of this discussion I'm using "resumption" to mean
both ordinary resumption [RFC 5246; Figure 2] and session tickets
[RFC 5077]. I tend to agree with the comments from others that if
we retain resumption we should unify these mechanisms, but that
seems like a question to be answered after we have decided
whether to retain resumption at all.

[1] Technical note: with RFC 5077 tickets the server retains the
ticket master key (TMK) in its memory, but since the attacker is
assumed to have the ticket, an attacker who successfully attacks the
server and recovers the TMK key can recover the MS. It's true that you
could store the TMK in secure storage, but you could also implement a
session cache where the entries are encrypted under some kind of
master key which is in secure storage, so I would argue that the
security properties vis-a-vis PFS are similar.

[2] For clarity, what I mean here is:

    Connection 1 does a full asymmetric exchange and establishes
    session X with MS key M, storing M in the session cache and
    using M to generate its keys.

    Connection 2 resumes session X and uses M to generate its keys.

    Connection 3 resumes session X and uses M to generate its keys.

It's fairly straightforward to have connection 1 generate two keys,
M and M' from its PMS, use M to generate its keys and store M'
in the session cache. But this still leaves both connection 2 and
3 sharing M'.

--001a11c38c7c2360d10505b4d067
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Folks,

I wanted to get t=
he discussion going on whether we need resumption [0] or not
for =
TLS 1.3. This may be a quick discussion as I suspect the answer is
yes, but I figure we should decide it rather than just assuming it.
=



The argument for resumption seems pretty=
 straightforward: it requires
significantly less computation (in =
the form of asymmetric operations)
than a full handshake. I suspe=
ct that this argument is less powerful
than it used to be for two=
 reasons:

- Increased computational power.
- Faster algorithms in the form of ECC.

Neverth=
eless, we still have constrained devices, both in the form of
low=
-power phones and IOT-type devices. OTOH, it's not clear to me
how many of those devices actually (a) do public key cryptography
as opposed to PSK and (b) do session resumption.


Conversely, resumption adds complexity to the protocol bot=
h since you
have to implement both the full and resumed state mac=
hines and because
the client has uncertainty about whether a serv=
er will accept
resumption.

Another probl=
em with resumption is that it is a threat to PFS.=C2=A0 In the
cu=
rrent TLS resumption design, if a session is resumable, then both
the client and the server retain the MS in their session caches [1].
=

Thus, even if you use a PFS cipher suite and destroy the traffic keys<=
/div>
and the asymmetric keys after the connection is over, an attacker=
 who
attacks the session cache can decrypt your connection. As no=
ted in my
previous message, it's not too difficult to separat=
e the MS stored in
the session cache from the MS used for the ini=
tial connection that
initiated the session, but it's much har=
der to do so between multiple
resumptions of the same session, th=
ough perhaps we could do figure out
how to do so [2].
<=
br>
I'm hoping to get people's opinions on this (and we c=
an discuss more
next week). How important is resumption to you as=
 a performance
optimization? Is it still important when you can d=
o all-ECC (which
it seems likely we will require clients to do fo=
r TLS 1.3).

-Ekr


[0] For purposes of this discussion I'm using "resumption&q=
uot; to mean
both ordinary resumption [RFC 5246; Figure 2] and se=
ssion tickets
[RFC 5077]. I tend to agree with the comments from =
others that if
we retain resumption we should unify these mechani=
sms, but that
seems like a question to be answered after we have =
decided
whether to retain resumption at all.

=

[1] Technical note: with RFC 5077 tickets the server retains the
=

ticket master key (TMK) in its memory, but since the attacker is
=

assumed to have the ticket, an attacker who successfully attacks the
server and recovers the TMK key can recover the MS. It's true =
that you
could store the TMK in secure storage, but you could als=
o implement a
session cache where the entries are encrypted under=
 some kind of
master key which is in secure storage, so I would a=
rgue that the
security properties vis-a-vis PFS are similar.

[2] For clarity, what I mean here is:

=C2=A0 =C2=A0 Connection 1 does a full asymmetric exchange and est=
ablishes
=C2=A0 =C2=A0 session X with MS key M, storing M in the =
session cache and
=C2=A0 =C2=A0 using M to generate its keys.

=C2=A0 =C2=A0 Connection 2 resumes session X and uses=
 M to generate its keys.

=C2=A0 =C2=A0 Connection =
3 resumes session X and uses M to generate its keys.

It's fairly straightforward to have connection 1 generate two keys,<=
/div>
M and M' from its PMS, use M to generate its keys and store M=
'
in the session cache. But this still leaves both connection=
 2 and
3 sharing M'.


=
=C2=A0 =C2=A0








--001a11c38c7c2360d10505b4d067--


From nobody Sat Oct 18 09:54:56 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963301A1B86 for ; Sat, 18 Oct 2014 09:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8Sb7ZX8RcC6 for ; Sat, 18 Oct 2014 09:54:52 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3591A1BA3 for ; Sat, 18 Oct 2014 09:54:51 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id m15so2750723wgh.26 for ; Sat, 18 Oct 2014 09:54:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C+LOH1QlUb1ktRgE7lDXsFphz1iTEDE3r2qSC0eSfa8=; b=TG+NWhE9MdqSeVOq3G+tvCtG/lxKpLnpul8wvJAfAUVAogxlOVjrw6+Uwt98P40eKK qWVzSxMcZfB6GvUo+j7Jt0/09RlVS+xKMyWiNqKz9NWiq7z1dx/Li+358AMe7k6ZY5Uo 7bAyXSHSms2q/nk6ObvoFHSuopjOuuNKPR9TyWWUlDLkoT8NLhE2a9fexokZ5sx9MH8W XFU15EXs3fn5Ky+qIzZOp9E2/5duXArK2dxAyCLBcy5s32pPT0ucd++MKyxDKmzsUc1f Drx0WEJOWIDzMnyZ9sll3hXguAzuvu5MIu1ACWE1LSpC2CRyNFtI5HIn42HlWp9TjjmU D0bQ==
X-Received: by 10.194.52.3 with SMTP id p3mr19315054wjo.93.1413651290645; Sat, 18 Oct 2014 09:54:50 -0700 (PDT)
Received: from [192.168.1.104] (IGLD-84-228-54-205.inter.net.il. [84.228.54.205]) by mx.google.com with ESMTPSA id gg18sm3449032wic.21.2014.10.18.09.54.49 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Oct 2014 09:54:50 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir 
In-Reply-To: 
Date: Sat, 18 Oct 2014 19:54:48 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/prtbQj-4DCyWWF71cbyBCznb4Qo
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 16:54:54 -0000

On Oct 18, 2014, at 7:16 PM, Eric Rescorla  wrote:

>=20
> The argument for resumption seems pretty straightforward: it requires
> significantly less computation (in the form of asymmetric operations)
> than a full handshake. I suspect that this argument is less powerful
> than it used to be for two reasons:
>=20
> - Increased computational power.
> - Faster algorithms in the form of ECC.
>=20

There=E2=80=99s one other thing, that is relevant for HTTPS, which is =
the biggest use case for TLS. The trend in recent years is that the TCP =
connections (and thus, TLS sessions) last for far longer than they used =
to.

This trend started with HTTP/1.1, but it=E2=80=99s now common for TLS =
sessions to last for many minutes as long as the browser window remains =
open.Since the original session lasts and lasts, there is less use for =
resumption.=20

The latest figures I=E2=80=99ve heard were of 50% of sessions being =
resumed, which is still a lot, but far less than it used to be 10 years =
ago, when both browsers and servers typically closed TCP connections =
after several seconds of inactivity. Still, assuming PK operations =
account for a large chunk of a server=E2=80=99s CPU cycles (and it is so =
in some common benchmark tests), eliminating resumption can reduce a =
server=E2=80=99s session rate by up to 50%.

With HTTP/2 poised to get deployed on much of the Internet, that 50% =
figure (that I suspect is driven by browsers opening several =
simultaneous connections before a session cache entry is available) is =
likely to be reduced further.

Yoav



From nobody Sat Oct 18 10:47:02 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CDB1A89A9 for ; Sat, 18 Oct 2014 10:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWou6knqfilF for ; Sat, 18 Oct 2014 10:46:59 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B981A89AB for ; Sat, 18 Oct 2014 10:46:58 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id DB4CC81816; Sat, 18 Oct 2014 20:46:55 +0300 (EEST)
Date: Sat, 18 Oct 2014 20:46:55 +0300
From: Ilari Liusvaara 
To: Watson Ladd 
Message-ID: <20141018174655.GB14006@LK-Perkele-VII>
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iyIV9YizhnSvnLT_68Odrx83prc
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Refactoring client auth/re-key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 17:47:01 -0000

On Sat, Oct 18, 2014 at 08:15:19AM -0700, Watson Ladd wrote:
> On Sat, Oct 18, 2014 at 7:32 AM, Eric Rescorla  wrote:
> >
> So I seem to remember DJB telling me that once you have a properly
> made channel via Diffie-Hellman, that authenticating requires just
> signing a value derived from the key. (Sadly I forgot/don't know the
> proof, so someone will have to check this or tell me I'm completely
> wrong) So we don't need the session hash to include the certificates,
> and so don't need to keep the running hash going past the first
> exchange.

AFAIK, It is sufficient (dunno if DJB told that).

The idea is: Ensure that keys are unique, even in face of active
attack, and only the (true) endpoints can compute those.

This can be done by hashing in transcript of negotiation and key
exchange into keys obtained from DH.

This causes the following:
- If attacker does not tamper with key exchange, the session key
  becomes unknowable.
- If attacker does tamper with key exchange, the two sides will not
  agree about keys (since keys are unique), and later channel
  authentication will fail.
- Attacker can't replay captured credentials, because keys will
  then be different from anything seen so far (uniqueness).


There's a subtle trap here tho: The authentication messages have to be
exchanged via the channel itself, not out-of-band. Otherwise the
authentication is broken. Not much of an issue here.

> Concretely the idea would be as follows: A sends to B g^x, and B
> responds with g^y. Both calculate MS=H(g^xy, g^x, g^y). (Of course, we
> need to hash the actual messages.)

That doesn't quite work (why?) :-)

Hint: What's missing (and it is not "certificate")?

> At this point we can compute channel_AtoB_key=PRF(MS, "channel AtoB
> key"),  channel_BtoA_key=PRF(MS, "channel BtoA key"),
> A_authstr=PRF(MS, "A authstr"), B_authstr=PRF(MS, "B authstr"). The
> channel keys can be used to encrypt each side as in the proposal, and
> the authstrs can be signed and sent over the channel to provide a
> proof of identity. Furthermore, we could extract a channel binding in
> an analogous manner, or application level keys in the same way, or a
> resumption key in the same way.

One subtle decision: Is there a split beween "system" (TLS uses
internally) and "user" keys (handed to application via TLS-EXTRACTOR).

One could imagine that with some of the proposals about fixing key
deriviation, some would want that.

Also, if there is no finished with nontrivial data, one would need
to derive a fake binding value for backward compatiblity (but that's
easy to do).


Also, due to some signature schemes having some real-world nonideal
properties, one wants to also throw the keys used into the message
(easiest way is to throw the whole certificate or hash thereof in).

Also, do client signatures need replay protection (prevents replaying
te same certificate in the same connection)?


Also, could be useful to have some sort of "label" along with client
certificate that gets notified along with the certificate to the
application.

The idea is that TLS would not process the client certificates more
than just validating the signature. Instead, if validation succeeds,
it would fire callback to application, reporting that certificate with
label X and contets Y has been successfully validated.

Then the application could calculate what to do with the certificate
and have latter communications refer to the certificate.

This is AFAIK needed with some applications (along with some more app-
level signaling) to use client authentication safely.


-Ilari


From nobody Sat Oct 18 11:18:50 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7C41A8A4A for ; Sat, 18 Oct 2014 11:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OX-mqS90AFbK for ; Sat, 18 Oct 2014 11:18:34 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B709D1A8A50 for ; Sat, 18 Oct 2014 11:18:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=t1dtKfRukArhSNoA0TgMxb74eRpK1k6lC8xX7JKHtVo=;  b=HuxLO5cTCaRHF8FyOhhaw25tRCDltAC+2XpHDbknH6a8ugw/XMYhoi/myFJHgKrG0aedx8535ZOk5r56HTun1X2/8fex5vtlNOzIYXyR/a012zpKIoANc/zNCvM5S9IGgduP59TolDvo3Y8Y1qyxesXbkBB7GvmY/SXPy+N4owM=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XfYaB-0005qA-8c; Sat, 18 Oct 2014 20:18:27 +0200
Message-ID: <5442AEF6.7030904@polarssl.org>
Date: Sat, 18 Oct 2014 20:18:30 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Eric Rescorla , "tls@ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Lyb34RNfWlvc8cmGH-_mmtmOad4
Subject: Re: [TLS] Refactoring client auth/re-key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 18:18:36 -0000

On 18/10/2014 16:32, Eric Rescorla wrote:
> Currently TLS has a single Master Secret which is used to compute
> directional traffic keys. Instead, we should have two unidirectional
> MSs, each initially generated from the initial PMS. E.g.,
> 
>       master_secret_client = PRF(pre_master_secret, "master secret_client",
>                                  ClientHello.random + ServerHello.random)
>                                  [0..47];
> 
>       master_secret_server = PRF(pre_master_secret, "master secret_server",
>                                  ClientHello.random + ServerHello.random)
>                                  [0..47];
> 
When you write "ClientHello.random + ServerHello.random", don't you rather mean
"transcript so far"?

Manuel.


From nobody Sat Oct 18 11:32:57 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C631A00F7 for ; Sat, 18 Oct 2014 11:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2IqqihZXRuF for ; Sat, 18 Oct 2014 11:32:51 -0700 (PDT)
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AAF1A006F for ; Sat, 18 Oct 2014 11:32:50 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so1922960qgf.35 for ; Sat, 18 Oct 2014 11:32:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gv3svWDG8YJI7a227aDl9OFu9LIQxVxNf4oy/obtBhc=; b=QUynpg6pB4n6nnUIqGAEc7NhaVZSG4E8LCka+z0auhdxY3fDV9rAxzu0uMBRhYYz4L nU/UccYvlLwTMzQ43HJyxiZDsiq/iS40B6V85vOv7BKsAU2opN4j7lKUR2MMvYLCAzHE EAq24ea6N6ZaL4BMWwQdAWCgwYiQ9k2qmjZmD5MXqz93bzshGLLxNhgHSQaROLXTmvhK RyfGuzzboLz3mRC+UlQQ254Cv9HUv6E349jOX8xpCu517LrGtcynCY12xES65d+UeOMK MPZs0Q7PPja/t4Asd3KCcUUvhDuSvZ9fbms2A4oIVmPBIfLgrz9/7s0cKrZppmbhiqmt 6/Qg==
X-Gm-Message-State: ALoCoQmn+Qi+7MVB/FJnB6bdzPxoFwtl1+Ebj3egddqLaNwBTdjxh0uNrtgfdQl1XQP34ikd1tWo
MIME-Version: 1.0
X-Received: by 10.140.29.101 with SMTP id a92mr19462448qga.41.1413657170105; Sat, 18 Oct 2014 11:32:50 -0700 (PDT)
Received: by 10.96.166.35 with HTTP; Sat, 18 Oct 2014 11:32:50 -0700 (PDT)
X-Originating-IP: [67.168.161.122]
In-Reply-To: <54B025040D4F68B1E49919B8@nifty-silver.us.oracle.com>
References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> <20141004033546.GG13254@mournblade.imrryr.org> <20141002175446.6EB7B1AEA6@ld9781.wdf.sap.corp> <54B025040D4F68B1E49919B8@nifty-silver.us.oracle.com>
Date: Sat, 18 Oct 2014 11:32:50 -0700
Message-ID: 
From: Joseph Salowey 
To: Chris Newman 
Content-Type: multipart/alternative; boundary=001a113b526a75711a0505b6b5b1
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_X0-PGvtyXKFWRYP0J0rgC4W4zw
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 18:32:53 -0000

--001a113b526a75711a0505b6b5b1
Content-Type: text/plain; charset=UTF-8

The main concern that I have with this approach is that attacks against RC4
will only get better and while the attacks may be currently impractical
against HTTP cookies perhaps there are other usages where the problem may
be greater.

Pragmatically, implementers will do what is necessary to interoperate, so I
think something along the lines of what Chris recommends below may be the
best way forward.    I'm a bit reluctant to bring opportunistic security
into the discussion at this point, but I think the rest is OK.

Do folks think this is an acceptable way forward?

Thanks,

Joe



On Wed, Oct 15, 2014 at 4:40 PM, Chris Newman 
wrote:

> I agree with this:
>
> --On October 4, 2014 3:35:47 +0000 Viktor Dukhovni  >
> wrote:
> > Well, I for one am not.   Disabling RC4 does more harm than good
> > with opportunistic TLS.  A far better approach in that case is to
> > de-priorioritize it.  Giving some check-list enforcing clue-less
> > auditor the ammunition to harass users into counter-productive
> > "security" measures is not my idea of progress.
> > ...
> > Not all applications face the same risks, and removing RC4 will some
> > applications *less* secure at least some of the time.
>
> As an implementer of a product with TLS/SSL support, I will ignore the
> three
> MUST/MUST NOT statements in this draft. As long as the SSL/TLS library I
> use
> supports RC4, I'm going to support RC4. And I'll be reluctant to upgrade
> to an
> SSL/TLS library that doesn't support RC4 for fear of breaking customer
> interoperability and forcing opportunistic connections to clear text.
>
> I believe the goal should be to replace RC4 usage in the real world with
> use of
> stronger cipher suites. I do not believe the current draft will advance
> that
> goal. Statements similar to the single-DES advice in RFC 5469 may advance
> that
> goal. Here are other statements that may advance that goal:
>
> * SSL/TLS software MUST prefer stronger cipher suites (presently AES and
> 3DES)
> over RC4.
>
> * SSL/TLS libraries MUST disable RC4 cipher suites by default. An
> application
> MUST make an explicit SSL/TLS library API call to enable RC4 cipher suites
> if
> they are needed for backwards compatibility.
>
> * SSL/TLS software MUST disable RC4 cipher suites when TLS 1.1 or 1.2 are
> negotiated and SHOULD disable RC4 cipher suites by default when earlier
> versions are negotiated. For an opportunistic security transmission, such
> as
> for SMTP relay (RFC 3207), RC4 MAY be used as a last resort for
> interoperability prior to fallback to transmission without SSL/TLS.
>
> * User agents that employ SSL/TLS for security MUST NOT indicate the
> connection
> is secure when RC4 is used. For example, a web browser that displayed a
> lock
> icon when an RC4 cipher suite was used would fail to comply with this
> requirement.
>
>                 - Chris
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a113b526a75711a0505b6b5b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The main concern that I have with this approach is that at=
tacks against RC4 will only get better and while the attacks may be current=
ly impractical against HTTP cookies perhaps there are other usages where th=
e problem may be greater.=C2=A0

Pragmatically, implement=
ers will do what is necessary to interoperate, so I think something along t=
he lines of what Chris recommends below may be the best way forward. =C2=A0=
 =C2=A0I'm a bit reluctant to bring opportunistic security into the dis=
cussion at this point, but I think the rest is OK. =C2=A0

Do folks think this is an acceptable way forward?

Thanks,

Joe


<=
/div>

On Wed=
, Oct 15, 2014 at 4:40 PM, Chris Newman <chris.newman@oracle.com=
> wrote:
I agree with this:



--On October 4, 2014 3:35:47 +0000 Viktor Dukhovni <ietf-dane@dukhovni.org>

wrote:

> Well, I for one am not.=C2=A0 =C2=A0Disabling RC4 does more harm than =
good

> with opportunistic TLS.=C2=A0 A far better approach in that case is to=


> de-priorioritize it.=C2=A0 Giving some check-list enforcing clue-less<=
br>
> auditor the ammunition to harass users into counter-productive

> "security" measures is not my idea of progress.

> ...

> Not all applications face the same risks, and removing RC4 will some
> applications *less* secure at least some of the time.



As an implementer of a product with TLS/SSL support, I will ignore the thre=
e

MUST/MUST NOT statements in this draft. As long as the SSL/TLS library I us=
e

supports RC4, I'm going to support RC4. And I'll be reluctant to up=
grade to an

SSL/TLS library that doesn't support RC4 for fear of breaking customer<=
br>
interoperability and forcing opportunistic connections to clear text.



I believe the goal should be to replace RC4 usage in the real world with us=
e of

stronger cipher suites. I do not believe the current draft will advance tha=
t

goal. Statements similar to the single-DES advice in RFC 5469 may advance t=
hat

goal. Here are other statements that may advance that goal:



* SSL/TLS software MUST prefer stronger cipher suites (presently AES and 3D=
ES)

over RC4.



* SSL/TLS libraries MUST disable RC4 cipher suites by default. An applicati=
on

MUST make an explicit SSL/TLS library API call to enable RC4 cipher suites =
if

they are needed for backwards compatibility.



* SSL/TLS software MUST disable RC4 cipher suites when TLS 1.1 or 1.2 are
negotiated and SHOULD disable RC4 cipher suites by default when earlier

versions are negotiated. For an opportunistic security transmission, such a=
s

for SMTP relay (RFC 3207), RC4 MAY be used as a last resort for

interoperability prior to fallback to transmission without SSL/TLS.



* User agents that employ SSL/TLS for security MUST NOT indicate the connec=
tion

is secure when RC4 is used. For example, a web browser that displayed a loc=
k

icon when an RC4 cipher suite was used would fail to comply with this

requirement.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Chris




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--001a113b526a75711a0505b6b5b1--


From nobody Sat Oct 18 11:45:56 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148FB1A00F9 for ; Sat, 18 Oct 2014 11:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5ljAI190aPo for ; Sat, 18 Oct 2014 11:45:54 -0700 (PDT)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F821A00F7 for ; Sat, 18 Oct 2014 11:45:53 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id hi2so3466988wib.14 for ; Sat, 18 Oct 2014 11:45:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HXK7t5CG5hG1T/hZdy+ObyNUcv+UPnhuaPh+kAxYsw4=; b=gZIP3nUj4x5Y9GmmZcBoXtKCjccOr+ys61jrv4FY4L1VPdDthgcWExHjWct+A6J4YW Yu4G2Y8j+sO8snlt8qxzjG+gMb8ZXXAs7k5spGGR9yZ4XvpTlZyfRbvNeL3RIKM+Ev3f zNkck72l0A8L1Mmw8CX6HpKrX+O3DfKbdgnoMt+rnD+0UcqfwuWW2LI0jsDzYOeBy0no lBJRzAMrSUovXGp40xJ6u+mguxoKg9V5HThfKOBSk5xZinZoB3nT9fDcJ2+McpXozum4 6K883Gie5myuXsKmYuQJyZoovszafcWe9outJWEZO/TEhcIt/y7fugfMw0jc83u/W3M1 8NnQ==
X-Gm-Message-State: ALoCoQkWO0N7nyeuh8j7cGdlAxL5rygZ0qP1mXsWH0KquviMhjWkf5NoNOQzP78F+fciAjzJDA6X
X-Received: by 10.194.242.4 with SMTP id wm4mr19340617wjc.61.1413657952553; Sat, 18 Oct 2014 11:45:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Sat, 18 Oct 2014 11:45:12 -0700 (PDT)
In-Reply-To: <5442AEF6.7030904@polarssl.org>
References:  <5442AEF6.7030904@polarssl.org>
From: Eric Rescorla 
Date: Sat, 18 Oct 2014 19:45:12 +0100
Message-ID: 
To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= 
Content-Type: multipart/alternative; boundary=089e01419af618c32e0505b6e459
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4Drj8CNxmK7ETYxR6HrMRMyr69Y
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Refactoring client auth/re-key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 18:45:55 -0000

--089e01419af618c32e0505b6e459
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 18, 2014 at 7:18 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard 
wrote:

> On 18/10/2014 16:32, Eric Rescorla wrote:
> > Currently TLS has a single Master Secret which is used to compute
> > directional traffic keys. Instead, we should have two unidirectional
> > MSs, each initially generated from the initial PMS. E.g.,
> >
> >       master_secret_client =3D PRF(pre_master_secret, "master
> secret_client",
> >                                  ClientHello.random + ServerHello.rando=
m)
> >                                  [0..47];
> >
> >       master_secret_server =3D PRF(pre_master_secret, "master
> secret_server",
> >                                  ClientHello.random + ServerHello.rando=
m)
> >                                  [0..47];
> >
> When you write "ClientHello.random + ServerHello.random", don't you rathe=
r
> mean
> "transcript so far"?


Good catch. I do indeed.

Thanks,
-Ekr


> Manuel.
>

--089e01419af618c32e0505b6e459
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Sat, Oct 18, 2014 at 7:18 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard <mpg@pol=
arssl.org> wrote:
On 18/10/2014 16:32, Eric Rescorla wrote:

> Currently TLS has a single Master Secret which is used to compute

> directional traffic keys. Instead, we should have two unidirectional
> MSs, each initially generated from the initial PMS. E.g.,

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0master_secret_client =3D PRF(pre_master_secr=
et, "master secret_client",

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ClientHello.random + Serve=
rHello.random)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [0..47];

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0master_secret_server =3D PRF(pre_master_secr=
et, "master secret_server",

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ClientHello.random + Serve=
rHello.random)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [0..47];

>

When you write "ClientHello.random + ServerHello.random", =
don't you rather mean

"transcript so far"?

Good catch. =
I do indeed.

Thanks,
-Ekr

=



Manuel.





--089e01419af618c32e0505b6e459--


From nobody Sat Oct 18 12:10:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EC71A0115 for ; Sat, 18 Oct 2014 12:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.737
X-Spam-Level: 
X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WddkFcQnCX2H for ; Sat, 18 Oct 2014 12:10:06 -0700 (PDT)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08AD81A00FD for ; Sat, 18 Oct 2014 12:10:05 -0700 (PDT)
Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XfZO7-0001Q5-Lt for tls@ietf.org; Sat, 18 Oct 2014 21:10:04 +0200
Received: from S0106001b21018173.vc.shawcable.net ([50.67.244.183]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 Oct 2014 21:10:03 +0200
Received: from yuhongbao_386 by S0106001b21018173.vc.shawcable.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 Oct 2014 21:10:03 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: tls@ietf.org
From: Yuhong Bao 
Date: Sat, 18 Oct 2014 19:03:07 +0000 (UTC)
Lines: 9
Message-ID: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>    
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 50.67.244.183 (Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nQWdIY7VecbYAjAjNIECqrnYRfY
Subject: Re: [TLS] =?utf-8?q?The_TLS=5FFALLBACK=5FSCSV_time_bomb_=28was=3A_Re?= =?utf-8?q?=3A_Working_Group_Last_Call_for_draft-ietf-tls-downgrade-scsv-0?= =?utf-8?q?0=29?=
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 19:10:09 -0000

Bodo Moeller  acm.org> writes:
> Even once we no longer need to worry about extension *intolerant* servers,
we still should take into account that extension *support* remains optional
for TLS servers. Servers can legitimately ignore ClientServer.extensions
entirely. Having a fallback_indication TLS extension would be overly onerous
for such servers: they'd need to implement extension parsing just to be able
to find this one signal. 
MS had to do this in order to backport the TLS renegotiation extension to
XP/Server 2003 back in 2010.


From nobody Sat Oct 18 14:56:04 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46241A1B27 for ; Sat, 18 Oct 2014 14:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeCCdKKcBOaZ for ; Sat, 18 Oct 2014 14:56:00 -0700 (PDT)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E421A1B34 for ; Sat, 18 Oct 2014 14:56:00 -0700 (PDT)
Received: by mail-yk0-f170.google.com with SMTP id 20so1229384yks.1 for ; Sat, 18 Oct 2014 14:56:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uxozVz264jYRFC0LOxobOGy2xdch6lurmA/h+BqEk6c=; b=KSr7hbgHO9u8IyMrtdFLcq5woURIBAxgwN+9oD4fbVIo2mtAcUJO2b3Sj98KUmUHm4 bvQhEWLW/LwuCAYbMTiW9dmlLrCaKEojSCB1llFsLcDGRYSmfUqWV65inH8/P6ArEMMp ZeMFvOfhvnmOe55dpo0/MOiWmlyXvIOr3G3giN6cXVx6lh3+2muY4369IckcsZW28yYj kuVXm2DxoELTmrVB7Dqv6FHCNzGzRvotU10OXIDgcnP1MyteHpWryBQJPtz5IfTUxg4+ K8dJ4aqsIx8hMEQzRDwcO7ghurk5jHnhFA41M638/eZdwnG+XUoTFl0I9zaNqP1uW+YU YO7A==
MIME-Version: 1.0
X-Received: by 10.236.45.7 with SMTP id o7mr46046yhb.169.1413669359875; Sat, 18 Oct 2014 14:55:59 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Sat, 18 Oct 2014 14:55:59 -0700 (PDT)
In-Reply-To: 
References:   
Date: Sat, 18 Oct 2014 14:55:59 -0700
Message-ID: 
From: Watson Ladd 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9HIgtWXyxjo4wAZVt_rRp59pgP8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Refactoring client auth/re-key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 21:56:02 -0000

On Sat, Oct 18, 2014 at 9:10 AM, Eric Rescorla  wrote:
> Watson,
>
> Thanks for your comments.
>
> On Sat, Oct 18, 2014 at 4:15 PM, Watson Ladd  wrote:
>>
>> On Sat, Oct 18, 2014 at 7:32 AM, Eric Rescorla  wrote:
>> >
>> So I seem to remember DJB telling me that once you have a properly
>> made channel via Diffie-Hellman, that authenticating requires just
>> signing a value derived from the key. (Sadly I forgot/don't know the
>> proof, so someone will have to check this or tell me I'm completely
>> wrong) So we don't need the session hash to include the certificates,
>> and so don't need to keep the running hash going past the first
>> exchange.
>>
>> Concretely the idea would be as follows: A sends to B g^x, and B
>> responds with g^y. Both calculate MS=H(g^xy, g^x, g^y). (Of course, we
>> need to hash the actual messages.)
>>
>> At this point we can compute channel_AtoB_key=PRF(MS, "channel AtoB
>> key"),  channel_BtoA_key=PRF(MS, "channel BtoA key"),
>> A_authstr=PRF(MS, "A authstr"), B_authstr=PRF(MS, "B authstr"). The
>> channel keys can be used to encrypt each side as in the proposal, and
>> the authstrs can be signed and sent over the channel to provide a
>> proof of identity.
>
>
>
> Trying to think through this a bit, is this a generic comment on the
> session-hash proposal even for TLS 1.2 where they are careful to
> sign everything up to CertificateVerify? See:
>
> https://tools.ietf.org/html/draft-ietf-tls-session-hash-02#section-4.1

That struck me as an implementation driven decision, since
implementations keep a running hash for the Finished message, which is
repurposed in the session hash proposal. Furthermore, what I  proposed
only works because we are sending the identities over a secure
channel: otherwise an attacker could remove the client authentication
and replace it with their own, thus causing both sides to disagree
over what the authentication status is.

The session hash was designed to be as minor a change as possible to
TLS 1.2. I've got no interest in mixing security improvements with
massive changes, as that slows adoption big time. While you could make
a similar change to TLS 1.2, it would be unnecessarily large.

My only other comment is that this is a much larger change than
1.1->1.2. Perhaps we really should be honest and call it TLS 2.0.

Sincerely,
Watson Ladd
>
> Perhaps one of the authors of that document can weigh in here.
>
> Best,
> -Ekr
>
>
>



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


From nobody Sat Oct 18 21:13:08 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B211A014C for ; Sat, 18 Oct 2014 21:13:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level: 
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrqO8vEzudDH for ; Sat, 18 Oct 2014 21:12:58 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38EB31A0126 for ; Sat, 18 Oct 2014 21:12:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413691980; x=1445227980; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=A5tmO1XCMwbMxEu/UlO22RD90FykHWOjnbzN2WHLOBc=; b=By+7+KBHTaBRK8RXDo2phABKdv7l8KlJQCC1k4+N3VVPe7vu2K095oOc Ju0S/u3AuIyKgQfieZr8ldDqiDQb3+Mw1kDcJfHVBDe+cZYC3v8Ux5nuu XC2hZfv9PrZOXzXxR/TmdvVdBz2lsU8/ZOwccjyFOi/M3MEl4nv1SWgrX s=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="284093803"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Oct 2014 17:12:56 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sun, 19 Oct 2014 17:12:54 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Fate of resumption
Thread-Index: Ac/rUvS9phLFSr5DQF6lXJQJycl6Xw==
Date: Sun, 19 Oct 2014 04:12:54 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D2984@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/plQqth91Tin9NzBgagsUTt3W_2Y
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 04:13:04 -0000

Yoav Nir  writes:=0A=
=0A=
>This trend started with HTTP/1.1, but it=92s now common for TLS sessions t=
o=0A=
>last for many minutes as long as the browser window remains open.Since the=
=0A=
>original session lasts and lasts, there is less use for resumption.=0A=
=0A=
And the important point here is "browser window remains open".  Vast number=
s=0A=
of TLS uses aren't browsers (it's the universal substrate for secure=0A=
connections over the net), they close and reopen the connection as needed.=
=0A=
Dropping resume would be a catastrophic performance hit for them.  I've wor=
ked=0A=
with devices that have cache expiry times of 24 hours or more, the planning=
=0A=
for them is that the high-overhead initial full handshake is something they=
=0A=
have to put up with in order to bootstrap an entry in the session cache, at=
=0A=
which point they can operate normally.=0A=
=0A=
>With HTTP/2 poised to get deployed on much of the Internet, =0A=
=0A=
Given its embedded-device-hostile nature (and the http-ng WG's response of=
=0A=
"let them eat HTTP 1.1"), it may get widely deployed for the browser-based=
=0A=
web, but I don't know about everything else.=0A=
=0A=
Peter.=


From nobody Sat Oct 18 21:13:50 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAF11A026C for ; Sat, 18 Oct 2014 21:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5c82Cga2cVE for ; Sat, 18 Oct 2014 21:13:46 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C67A1A014C for ; Sat, 18 Oct 2014 21:13:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413692028; x=1445228028; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=icN68bpoqDgHb+gmDWM0jvPyJlrDopkcP+WZ2E5k81Y=; b=Bqu6iyG49fETqcd67ohoEdWKZUuorlwHbAEzHu6eAJXSffyRR5h9cvne aI1b6D6ZszTrOQmRdK3dRgeW9u6wZco/ilE7icD88P2bzdaEpbfIa239Z ErZE7AVRYO24dYQRgJ5nu1ErOzv3MUdv/Za8UIECvyudeVV0B9EAfuGSp k=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="284093837"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Oct 2014 17:13:46 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sun, 19 Oct 2014 17:13:44 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: Ac/rUxJ+nD9tEJYuSL6aCRNDMCW07Q==
Date: Sun, 19 Oct 2014 04:13:44 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D2991@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pP5R0rOsfa7ou3IF4mYGtYNNphA
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 04:13:48 -0000

Andrei Popov  writes:=0A=
=0A=
>I think about 60-90 days or so, for those clients and servers that get=0A=
>regular updates.=0A=
=0A=
... and 5,000 days for clients and servers where you have to wait for the=
=0A=
hardware to die in order to see an update.=0A=
=0A=
(10,000 days is probably on the long side, but I still have to maintain=0A=
backwards-compatible bugfixes for SSH versions from the late 1990s in major=
=0A=
backbone routing gear, so we're talking a 15-year lifespan at least, which =
is=0A=
where the 5K days came from).=0A=
=0A=
Oh, and given your affiliation, I was tempted to add: "So Microsoft are=0A=
planning to roll out an update to Windows XP then?" :-).=0A=
=0A=
Peter.=


From nobody Sat Oct 18 23:57:34 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334761A1BF8 for ; Sat, 18 Oct 2014 23:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.559
X-Spam-Level: 
X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sb13sl5m_S2t for ; Sat, 18 Oct 2014 23:57:29 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9301F1A1BF7 for ; Sat, 18 Oct 2014 23:57:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.04,749,1406584800";  d="asc'?scan'208,217";a="83795060"
Received: from 244.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.244]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 19 Oct 2014 08:57:25 +0200
Content-Type: multipart/signed; boundary="Apple-Mail=_201C1A0C-5812-4D8B-B8C2-81E456E60267"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Karthikeyan Bhargavan 
In-Reply-To: 
Date: Sun, 19 Oct 2014 08:57:25 +0200
Message-Id: <94F22FB7-ACA4-407C-8528-E806DFA64F54@inria.fr>
References:   
To: Eric Rescorla 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gXzkdb4HMxRyIPGwgnokDEU4DDI
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Refactoring client auth/re-key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 06:57:32 -0000

--Apple-Mail=_201C1A0C-5812-4D8B-B8C2-81E456E60267
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8040F8E6-D051-4DA9-9579-473D4EC20077"


--Apple-Mail=_8040F8E6-D051-4DA9-9579-473D4EC20077
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


> So I seem to remember DJB telling me that once you have a properly
> made channel via Diffie-Hellman, that authenticating requires just
> signing a value derived from the key. (Sadly I forgot/don't know the
> proof, so someone will have to check this or tell me I'm completely
> wrong) So we don't need the session hash to include the certificates,
> and so don't need to keep the running hash going past the first
> exchange.

At least one form of this construction (as used in IKEv2) is =
well-explained=20
and proved in the original SIGMA paper:
http://www.iacr.org/cryptodb/data/paper.php?pubkey=3D1495


> Trying to think through this a bit, is this a generic comment on the
> session-hash proposal even for TLS 1.2 where they are careful to
> sign everything up to CertificateVerify? See:

As Ilari hints, it is not enough to hash the client-server key shares =
into
the master secret. In a negotiated protocol like TLS, we need to add
the DH parameters, the algorithms used to derive the keys, and the
algorithms that the resulting key will be used with. (The crypto proofs
typically fix these values and so they don=92t necessarily appear in the
academic protocols.)

For session hash in TLS 1.2, the log up to ClientKeyExchange contains
all this data, and we need to hash at least the Hellos and the =
KeyExchanges.
So even if the client and server are anonymous the session hash context =
binds the master secret.

One may argue that the client and server authenticated identities =
(Certificates) do not
need to be included in the session hash. This would be true for the =
initial handshake,
but not for resumption. One use of the TLS 1.2 master secret is as a key =
for session
resumption, and the Triple Handshake attack relies on the master secret =
not being
bound to the peer=92s identity.=20

For TLS 1.3, I need to stare about the Update protocol a bit more, but I =
think authentication
after an initial DH handshake could be made safe (a la SSH and IKEv2). =
That is,
the first master secret hashes the keyshares, and the second master =
secret/connection key
hashes in the identities.=20

The question that bothers me is which key/master secret would we use for =
session resumption? If it is the initial (unauthenticated) master =
secret, I think there will be attacks.=20
If we only allow the last (authenticated) master secret to be resumed, =
we would probably
recover the guarantees of session hash.=20




>=20
> https://tools.ietf.org/html/draft-ietf-tls-session-hash-02#section-4.1
>=20
> Perhaps one of the authors of that document can weigh in here.
>=20
> Best,
> -Ekr
>=20
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--Apple-Mail=_8040F8E6-D051-4DA9-9579-473D4EC20077
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


So I seem to remember DJB telling me that once you have a =
properly
made channel via Diffie-Hellman, that authenticating =
requires just
signing a value derived from the key. (Sadly I =
forgot/don't know the
proof, so someone will have to check this or =
tell me I'm completely
wrong) So we don't need the session hash to =
include the certificates,
and so don't need to keep the running hash =
going past the =
first
exchange.

At least one form of this construction (as used =
in IKEv2) is well-explained 
and proved in the original =
SIGMA paper:


Trying to think =
through this a bit, is this a generic comment on =
the
session-hash proposal even for TLS 1.2 where they are =
careful to
sign everything up to CertificateVerify? =
See:

A=
s Ilari hints, it is not enough to hash the client-server key shares =
into
the master secret. In a negotiated protocol like TLS, we =
need to add
the DH parameters, the algorithms used to derive =
the keys, and the
algorithms that the resulting key will be =
used with. (The crypto proofs
typically fix these values and =
so they don=92t necessarily appear in the
academic =
protocols.)

For session hash in TLS 1.2, the =
log up to ClientKeyExchange contains
all this data, and we =
need to hash at least the Hellos and the KeyExchanges.
So even =
if the client and server are anonymous the session hash context binds =
the master secret.

One may argue that the =
client and server authenticated identities (Certificates) do =
not
need to be included in the session hash. This would be =
true for the initial handshake,
but not for resumption. One =
use of the TLS 1.2 master secret is as a key for =
session
resumption, and the Triple Handshake attack relies on =
the master secret not being
bound to the peer=92s =
identity. 

For TLS 1.3, I need to stare =
about the Update protocol a bit more, but I think =
authentication
after an initial DH handshake could be made =
safe (a la SSH and IKEv2). That is,
the first master secret =
hashes the keyshares, and the second master secret/connection =
key
hashes in the =
identities. 

The question that bothers me =
is which key/master secret would we use for session resumption? If it is =
the initial (unauthenticated) master secret, I think there will be =
attacks. 
If we only allow the last (authenticated) =
master secret to be resumed, we would probably
recover the =
guarantees of session =
hash. 






Perhaps one of the authors of that =
document can weigh in =
here.

Best,
-Ekr

=



______________=
_________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/tls

=

--Apple-Mail=_8040F8E6-D051-4DA9-9579-473D4EC20077--

--Apple-Mail=_201C1A0C-5812-4D8B-B8C2-81E456E60267
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJUQ2DVAAoJEB/WSo9veuUKPWkIAIu1Uz1HWtWJAXdik23KdbG8
9yhnB8AIc2bGz9AUNzfACIgLxHXQj5lkqOrFaGnOEIF1ssYRv5L/5AMqQJFpzGv3
vOk4dzEWi2bLc2ht3UNUJ7QLUxm2Kktf0eFAJ7Ip7yS3kVr/WcQrhepcvy8u01Lu
KVQkBRZhihUkYjBg9nUea11Nq0T6BRVruSLyMuB0c2lOeaBUXIG6vae0g8sCVC9U
GoJJlEO+JhzImRM0S0TvngkFQ4JbggacxM+p0+A+FBRfleuXNGmMY9CpDJfz9Cv5
hEHOV8ONeZy1Dtuvb8xdbuPHjxrb3fx/x6AEoxMWQ3PCy1wUTI1rCx2ln+p5eWw=
=HJ/b
-----END PGP SIGNATURE-----

--Apple-Mail=_201C1A0C-5812-4D8B-B8C2-81E456E60267--


From nobody Sun Oct 19 00:44:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102761A001A for ; Sun, 19 Oct 2014 00:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQuf31UUYf2Z for ; Sun, 19 Oct 2014 00:44:24 -0700 (PDT)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DAB1A0006 for ; Sun, 19 Oct 2014 00:44:24 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-03v.sys.comcast.net with comcast id 4vkJ1p0012VvR6D01vkPKF; Sun, 19 Oct 2014 07:44:23 +0000
Received: from [192.168.1.2] ([71.202.164.227]) by resomta-ch2-19v.sys.comcast.net with comcast id 4vkM1p00E4uhcbK01vkNH6; Sun, 19 Oct 2014 07:44:23 +0000
Message-ID: <54436BD5.9020107@brainhub.org>
Date: Sun, 19 Oct 2014 00:44:21 -0700
From: Andrey Jivsov 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Bodo Moeller , "tls@ietf.org" 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>	<5438CFEA.7000401@brainhub.org>	<5440CC7F.1020608@brainhub.org>		<54415A1F.3080707@brainhub.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020701080303000108050506"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413704663; bh=XY4g4YkwsLEsHTUOHOORlZno55ZCYHXdjTjjo2bLa4E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hfINKo9jxAhgtKswaq+hYPO2+p8+JK/9OBbO8aNU7JHnVLiXvUhaJkbDtf9OLs0Zo 6tLx0yt76IhtXSYL6/WT6OCga+c41S0e1pl9aokdxUqdtaVf7t1HAbnDi/xjeEUZp6 SrsouGvgJqaa2dPTlgFea+IYQgCBnYBYmLBOiQ8D5+waujjTotOmDJpY4CcamTsrC+ c3D+qJRT40R6a33378vlAxO4KQJdxqXWfZziUMKzDlXZWmtioI+Tk6Ck8YUdgBa7uB kbcvFE7QSU9F9pMVPXAluj7toOpG5I7xIKHnPiI+0QgdYJEfjDl4pd3oRUMJWw4SDE Kdd/lyZEHgNvQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ITXgKNhRB_4yw6dABtXbLfbIig0
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 07:44:31 -0000

This is a multi-part message in MIME format.
--------------020701080303000108050506
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10/18/2014 05:08 AM, Bodo Moeller wrote:
> Andrey Jivsov >:
>
>     The reality of the Internet today is that TLS 1.1 is viewed as
>     acceptable. Clients treating TLS 1.1 treating it this way too. The
>     draft *requires* to introduce a rejection of TLS 1.1 connection on
>     the server when the server detects the downgrade.
>
>
> According to the draft, this server-side rejection is REQUIRED *if the 
> client sent TLS_FALLBACK_SCSV to request it*. For the client, however, 
> it is merely RECOMMENDED to send TLS_FALLBACK_SCSV in all fallback 
> retries.

Thinking more about it, there are two issues I see with the above: 
"smart client / dumb server" model and SHOULD for the client use of 
TLS_FALLBACK_SCSV.


What was the rationale for the dumb server / smart client design?

Please allow me to suggest that the opposite might be equally viable: a 
client MUST include TLS_FALLBACK_SCSV (with any downgraded negotiation) 
and server SHOULD respond with an inappropriate_fallback alert.

Example. Most often the servers are the custodians of the information / 
content. Servers are managed by professionals and are properly 
maintained. A server security policy might require TLS 1.1 to access the 
content that it serves. When such a server receives a ClientHello with 
TLS 1.0, it might proceed with a handshake, but display an HTML page 
explaining that access was denied due to low security, perhaps adding 
how to remedy the problem. In the end this is more secure: the same 
result of denying access to information, but with a more informative 
message. Neither the server nor the client implementations may find it 
appealing to code a special warning message specifically to flag MiT 
downgrade attack when TLS_FALLBACK_SCSV is used (e.g. to avoid 
false-positives), however, the server may include some of this 
information on the above-mentioned page as well, or choose to send 
inappropriate_fallback alert.

>     My point is that downgrades from TLS1.0 to SSL3.0 is one thing but
>     from TLS1.3 to TLS1.2 is another.
>
>
> You appear to be saying that, carefully weighing the case, a silent 
> fallback to TLS 1.2 can be acceptable. I don't disagree: the spec 
> takes this into account, it's just that it leaves it to the *client* 
> to make this decision, without further *server*-side heuristics 
> interfering with it,.

Thank you for considering this issue, Bodo.
>
> (I think this makes sense because it's the client that decides whether 
> to do fallback retries in the first place. For clients that don't set 
> TLS_FALLBACK_SCSV at all, for example, any server-side enabled 
> protocol version can be negotiated anyway -- the server can't avoid 
> using old versions with such clients other than by disabling them 
> entirely.)

... Yet the server has the content.

Currently the client has SHOULD for TLS_FALLBACK_SCSV. Why is this one 
not MUST (regardless of the server MUST or SHOULD)?

This SHOULD for the client means that the client that implements the 
draft will use some logic to switch between cases:
a) as if doesn't implement the draft
b) client sends TLS_FALLBACK_SCSV with any downgraded negotiation

If client does a), perhaps by interpreting network errors, POODLE 
continues to live.

Is this intended for clients that allow end-users to tweak how SHOULD is 
interpreted?

If we have protocol dance on the client (heuristic #1) and SHOULD 
include TLS_FALLBACK_SCSV  (heuristic #2), this may complicate 
diagnosing this on the server.

I would say (regardless of the server SHOULD or MUST), that one is free 
not to implement the draft on the client. If he does, he MUST send the 
TLS_FALLBACK_SCSV on the downgrade.

--------------020701080303000108050506
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/18/2014 05:08 AM, Bodo Moeller
      wrote:

    

    

      

        

          
Andrey Jivsov <crypto@brainhub.org>:

          


            
The
              reality of the Internet today is that TLS 1.1 is viewed as
              acceptable. Clients treating TLS 1.1 treating it this way
              too. The draft *requires* to introduce a rejection of TLS
              1.1 connection on the server when the server detects the
              downgrade.

            

            


            

            
According to the draft, this server-side rejection is
              REQUIRED *if the client sent TLS_FALLBACK_SCSV to request
              it*. For the client, however, it is merely RECOMMENDED to
              send TLS_FALLBACK_SCSV in all fallback retries.

          

        

      

    

    

    Thinking more about it, there are two issues I see with the above:
    "smart client / dumb server" model and SHOULD for the client use of
    TLS_FALLBACK_SCSV. 

    

    

    What was the rationale for the dumb server / smart client design?

    

    Please allow me to suggest that the opposite might be equally
    viable: a client MUST include TLS_FALLBACK_SCSV (with any downgraded
    negotiation) and server SHOULD respond with an
    inappropriate_fallback alert. 

    

    Example. Most often the servers are the custodians of the
    information / content. Servers are managed by professionals and are
    properly maintained. A server security policy might require TLS 1.1
    to access the content that it serves. When such a server receives a
    ClientHello with TLS 1.0, it might proceed with a handshake, but
    display an HTML page explaining that access was denied due to low
    security, perhaps adding how to remedy the problem. In the end this
    is more secure: the same result of denying access to information,
    but with a more informative message. Neither the server nor the
    client implementations may find it appealing to code a special
    warning message specifically to flag MiT downgrade attack when
    TLS_FALLBACK_SCSV is used (e.g. to avoid false-positives), however,
    the server may include some of this information on the
    above-mentioned page as well, or choose to send
    inappropriate_fallback alert.

    

    

      

        

          

            
My
              point is that downgrades from TLS1.0 to SSL3.0 is one
              thing but from TLS1.3 to TLS1.2 is another.

            


            

            
You appear to be saying that, carefully weighing the
              case, a silent fallback to TLS 1.2 can be acceptable. I
              don't disagree: the spec takes this into account, it's
              just that it leaves it to the *client* to make this
              decision, without further *server*-side heuristics
              interfering with it,.

          

        

      

    

    

    Thank you for considering this issue, Bodo. 

    

      

        

          

            


            

            
(I think this makes sense because it's the client that
              decides whether to do fallback retries in the first place.
              For clients that don't set TLS_FALLBACK_SCSV at all, for
              example, any server-side enabled protocol version can be
              negotiated anyway -- the server can't avoid using old
              versions with such clients other than by disabling them
              entirely.)

          

        

      

    

    

    ... Yet the server has the content.

    

    Currently the client has SHOULD for TLS_FALLBACK_SCSV. Why is this
    one not MUST (regardless of the server MUST or SHOULD)?

    

    This SHOULD for the client means that the client that implements the
    draft will use some logic to switch between cases:

    a) as if doesn't implement the draft

    b) client sends TLS_FALLBACK_SCSV with any downgraded negotiation

    

    If client does a), perhaps by interpreting network errors, POODLE
    continues to live. 

    

    Is this intended for clients that allow end-users to tweak how
    SHOULD is interpreted?

    

    If we have protocol dance on the client (heuristic #1) and SHOULD
    include TLS_FALLBACK_SCSV  (heuristic #2), this may complicate
    diagnosing this on the server.

    

    I would say (regardless of the server SHOULD or MUST), that one is
    free not to implement the draft on the client. If he does, he MUST
    send the TLS_FALLBACK_SCSV on the downgrade.

  


--------------020701080303000108050506--


From nobody Sun Oct 19 01:15:59 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEB31A0037 for ; Sun, 19 Oct 2014 01:15:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gv9XYtLOugbe for ; Sun, 19 Oct 2014 01:15:56 -0700 (PDT)
Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51B71A002D for ; Sun, 19 Oct 2014 01:15:55 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id A92EC3FCB; Sun, 19 Oct 2014 11:15:52 +0300 (EEST)
Date: Sun, 19 Oct 2014 11:15:52 +0300
From: Ilari Liusvaara 
To: Karthikeyan Bhargavan 
Message-ID: <20141019081551.GA12098@LK-Perkele-VII>
References:    <94F22FB7-ACA4-407C-8528-E806DFA64F54@inria.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <94F22FB7-ACA4-407C-8528-E806DFA64F54@inria.fr>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9y_5Sylj_YL4L7tzvC8D7F1nL3w
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Refactoring client auth/re-key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 08:15:58 -0000

On Sun, Oct 19, 2014 at 08:57:25AM +0200, Karthikeyan Bhargavan wrote:
> 
> One may argue that the client and server authenticated identities
> (Certificates) do not need to be included in the session hash. This
> would be true for the initial handshake, but not for resumption. One
> use of the TLS 1.2 master secret is as a key for session resumption,
> and the Triple Handshake attack relies on the master secret not being
> bound to the peer’s identity. 

I think this is just wrong. And if it was true, you would have much
much worse problems.


- To defeat the renego fix, you need finished collision.
- To get finished collision, you need MS collision.
- MS collision is already damaging in itself.

If kex is passive-attack secure, MS hashes in kex parameters, exchange
keys, nonces (only needs to be unique across exchange key
offered) and kex result: Then MS collision impiles that kex
parameters, exchange keys and nonces are the same (kex result will be
the same too).

But since kex is passive-attack secure, MS will be unknowable for the
attacker, and any tampering will make handshake fail.

Now, for non-PFS key exchanges, certificates can contain exchange keys.
In practicular, RSA kex server certs do contain exchange key. And
thus under "hash exchange keys", you need to hash it.


In fact, one wants slightly stronger property: Each and every full
handshake computes a fresh MS never before seen, even if peer is
maliscous. But hashing the stuff listed above is sufficient for that,
because each (exchange key, nonce) pair from honest peers will be
unique, forcing the MS computed by those to be different (what
MS maliscous endpoints compute is no consideration).


The reason why one wants to also hash the crypto negotiation is to
avoid downgrade attacks.



-Ilari


From nobody Sun Oct 19 02:30:53 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A29F1A00AF for ; Sun, 19 Oct 2014 02:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9rtD4BBEzDf for ; Sun, 19 Oct 2014 02:30:51 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3931A00A9 for ; Sun, 19 Oct 2014 02:30:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:To:MIME-Version:From:Date:Message-ID; bh=Pj42+T8pmHF3R2z7f1eyTronXQhWyfwXp0Ye/5mUmY8=;  b=grsxdhoHBrJ64D+avfeWJ7kXCfKWUXTcREyOJ1IsXOOKtwoS3l7Nlv9F5M/XDmnndjFqvFp1y0/C+f1Xhg66yVUQq6W7cdRPFt3/ORg0yDN3WRQa9JdXcgMKKtIenYVVBGKlCl40vZWxJ83Owh7tyROhwbqaNc5dcFo/2YhGv4k=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xfmp2-0001ko-5n for tls@ietf.org; Sun, 19 Oct 2014 11:30:44 +0200
Message-ID: <544384C7.9030002@polarssl.org>
Date: Sun, 19 Oct 2014 11:30:47 +0200
From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "" 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4pi4BE53_JcjF2rRwcddQtEW9pw
Subject: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 09:30:52 -0000

Hi,

Sorry if this was discussed previously and I missed it, but I was wondering
about the fate of PSK in TLS 1.3. The RSA and (EC)DH key exchanges were removed
because they do not offer forward security. PSK does not offer FS either. OTOH,
it has very interesting performance properties, namely it's the only key
exchange that does not require asymmetric crypto.

It seems to me it makes a lot of sense to keep it, even if it doesn't give FS.

The reason I'm asking this now is the parallel discussion about new handshake
flows and possibly proving them secure. If we're keeping PSK, maybe it's good to
keep it in mind in this discussion, since it may have different properties than
(EC)DHE for the proofs/security discussion.

Manuel.


From nobody Sun Oct 19 02:38:07 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F1A1A00B0 for ; Sun, 19 Oct 2014 02:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zcZe5boGDJS for ; Sun, 19 Oct 2014 02:37:56 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E701A00AD for ; Sun, 19 Oct 2014 02:37:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=/lNOYFYZ1nwyMbT4Mo8/F50kUs7yuTyJIGKsU74aFeo=;  b=JEAbP6WSlOCWWxnkNk1cMIO4llQuabgbojCx9/t+IpsNo6PeKItbGxKvZmSsp2TjVdWejF0znrR/Ak+iwazJ1Q5Eyb/F5YANnYfSGORLPslcDImdBhZUdkGj+hLDG48LvWeGQuF0wtrAqD4tko+2T80jO5K8fXsI2YTIcQ4klv0=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xfmvu-0001lP-B7; Sun, 19 Oct 2014 11:37:50 +0200
Message-ID: <54438671.8060806@polarssl.org>
Date: Sun, 19 Oct 2014 11:37:53 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Fox Arcadia , tls@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NlzJXknB2mBVlm-_u0tpfYTi3C4
Subject: Re: [TLS] RFC5487 PSK Key Exchange Algorithm with SHA-256/384. Premaster secret if ciphersuites negotiated for TLS V1.2?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 09:37:57 -0000

Hi,

Sorry for replying so late, I hope this reply is still useful.

On 20/09/2014 09:51, Fox Arcadia wrote:
>  Note 2: Using zeroes for "other_secret" effectively means that
>       only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
>       is used when constructing the master secret.  This was considered
>       more elegant from an analytical viewpoint than, for instance,
>       using the same key for both the HMAC-MD5 and HMAC-SHA1 parts.  See
>       [KRAWCZYK ] for
> a more detailed rationale.
> 
IMO, this is only a rationale for using the zeroes, not a normative part.

> but if using a PRF defined in TLS V1.2, then HMAC-MD5 is not used but
> the HMAC defined by the PRF.
> 
> And, in that case, part of the used premaster is zeroes.
> 
Yes, in that case part of the PMS is zeroes, and it's fed to the TLS PRF (using
SHA256) as is, including the zeroes.

At least, that's what we do in PolarSSL and we never had interop issues (tested
regularly with OpenSSL and GnuTLS at least).

> should we in that case reuse PSK for other_secret?
> 
Nope.

Manuel.


From nobody Sun Oct 19 02:58:12 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D8C1A00E1 for ; Sun, 19 Oct 2014 02:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOf5ab6JTe4p for ; Sun, 19 Oct 2014 02:58:08 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BAB1A00B0 for ; Sun, 19 Oct 2014 02:58:07 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id em10so4967437wid.4 for ; Sun, 19 Oct 2014 02:58:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yjn+XqFsssQ5C3Ch9/KUZvNKlQNM+n2zu6rw595H1no=; b=YRb0i5Sq/wn/XkkOo0xKK/WNP3ZFA7xofuMjKLQpdhjAVF23Mt6jZxZ2hsbkdJQo3M HjvtbsUFauEB0QF2dzrSxC7NPzfN94jD2lfAGVb6rMh5TJpHepZnAWiIzS/1xT/LuYLU 9sjFuuB7ZJsP28I0Us2NUWWEvrrpruUB81i2KVdldt7H8LgV1HkEmA1ZjeXeuwBf0WAo 5P6nLHJQcFHcp5UhkMbziOQc4m1t7iVwgZa450s3rveggz8zHT1uVgWviXIyZe5Jyjm0 qVrjFW7VYHyv7+AU6/uc6saZn5wEYYNGyQ3FEylIppJMheXJMR9o5S1DLvwlOPpZdBT/ zOMw==
X-Received: by 10.180.86.38 with SMTP id m6mr11433134wiz.65.1413712686765; Sun, 19 Oct 2014 02:58:06 -0700 (PDT)
Received: from [192.168.1.98] (244.92.69.86.rev.sfr.net. [86.69.92.244]) by mx.google.com with ESMTPSA id l17sm1336780wiw.7.2014.10.19.02.58.05 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Oct 2014 02:58:06 -0700 (PDT)
From: Karthikeyan Bhargavan 
X-Google-Original-From: Karthikeyan Bhargavan 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <20141019081551.GA12098@LK-Perkele-VII>
Date: Sun, 19 Oct 2014 11:58:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D0BBEAE-F6D0-4D10-AFC5-5D9885CA48BB@inria.fr>
References:    <94F22FB7-ACA4-407C-8528-E806DFA64F54@inria.fr> <20141019081551.GA12098@LK-Perkele-VII>
To: Ilari Liusvaara 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IRHtady-Yfsi2Sk5V9QH0KtUdHI
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Refactoring client auth/re-key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 09:58:10 -0000

> Now, for non-PFS key exchanges, certificates can contain exchange =
keys.
> In practicular, RSA kex server certs do contain exchange key. And
> thus under "hash exchange keys", you need to hash it.

You=E2=80=99re right, including the peer identity applies mainly for =
non-PFS exchanges where
the peer=E2=80=99s keycard is closely linked to its identity (RSA, PSK, =
and Fixed DH/ECDH)=20
For DHE/ECDHE, if the client/server negotiate a known good group/curve, =
agreeing
upon the DH params should be enough. Since, by default, the server can =
choose an
arbitrary group, it seems prudent to include its identity.  =20



From nobody Sun Oct 19 04:45:06 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E821A0120 for ; Sun, 19 Oct 2014 04:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbyYxmSOWbgu for ; Sun, 19 Oct 2014 04:45:01 -0700 (PDT)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC1D1A0127 for ; Sun, 19 Oct 2014 04:44:57 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id hi2so5024035wib.15 for ; Sun, 19 Oct 2014 04:44:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H/LOVaHHuwgPR6CqAbRvFYIMsipIwYD2i1mVuccv5eg=; b=diECPcAAIVf+1pCWfHHEt9A5x4WYM2Bgi6IPHAoOzX5/Aa/L3dRgG+sNCOkBBcaumU yBQYkXNVcvL6mQKpHZBs/jdMQ46k+lPw6lQ9ylF6rJ2Oe1MjLomNKgrQuBG/SDilwEx+ DUnLHPaxc4MJrWRj7omo11oFRolHZYRTDX1FLPeXv41upil3YNRR2k11KaxtMUBDf+FN WVVGL7jvxZzqOqoPnE5ywqou+taBoEYXmIl9ZpoDk7GVuE/m0fyGidqzNvAD4lpgHunp YoGTZul+SZO0YBftrNDRMp7Q4WxzGro2bdK1xVQy7aWamLsSqSPhAJyGiGrjcxlgn+3m uBhA==
X-Gm-Message-State: ALoCoQmsRhqySgVggqS3I1Ukg/IdvvhlZLI9x2C1Vx9Pf7tmk5F+Ljn9MANYJGyzZu1aQuA4N8O+
X-Received: by 10.180.104.8 with SMTP id ga8mr12006652wib.78.1413719096736; Sun, 19 Oct 2014 04:44:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Sun, 19 Oct 2014 04:44:16 -0700 (PDT)
In-Reply-To: <544384C7.9030002@polarssl.org>
References: <544384C7.9030002@polarssl.org>
From: Eric Rescorla 
Date: Sun, 19 Oct 2014 12:44:16 +0100
Message-ID: 
To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= 
Content-Type: multipart/alternative; boundary=f46d0442713092f27e0505c52088
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0vlagSOkAWLrEfOTw6-uCnRIiXM
Cc: "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 11:45:03 -0000

--f46d0442713092f27e0505c52088
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the reminder.

I've been assuming we would keep it and trying to bear it in mind as I thin=
k
about design, but it's good to see this stated explicitly.

-Ekr


On Sun, Oct 19, 2014 at 10:30 AM, Manuel P=C3=A9gouri=C3=A9-Gonnard 
wrote:

> Hi,
>
> Sorry if this was discussed previously and I missed it, but I was wonderi=
ng
> about the fate of PSK in TLS 1.3. The RSA and (EC)DH key exchanges were
> removed
> because they do not offer forward security. PSK does not offer FS either.
> OTOH,
> it has very interesting performance properties, namely it's the only key
> exchange that does not require asymmetric crypto.
>
> It seems to me it makes a lot of sense to keep it, even if it doesn't giv=
e
> FS.
>
> The reason I'm asking this now is the parallel discussion about new
> handshake
> flows and possibly proving them secure. If we're keeping PSK, maybe it's
> good to
> keep it in mind in this discussion, since it may have different propertie=
s
> than
> (EC)DHE for the proofs/security discussion.
>
> Manuel.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f46d0442713092f27e0505c52088
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks for the reminder.

I've been =
assuming we would keep it and trying to bear it in mind as I think
about design, but it's good to see this stated explicitly.
=

-Ekr

On Sun, Oct 19, 2014 at 10:30 AM, Manuel P=C3=
=A9gouri=C3=A9-Gonnard <mpg@polarssl.org> wrote:
Hi,



Sorry if this was discussed previously and I missed it, but I was wondering=


about the fate of PSK in TLS 1.3. The RSA and (EC)DH key exchanges were rem=
oved

because they do not offer forward security. PSK does not offer FS either. O=
TOH,

it has very interesting performance properties, namely it's the only ke=
y

exchange that does not require asymmetric crypto.



It seems to me it makes a lot of sense to keep it, even if it doesn't g=
ive FS.



The reason I'm asking this now is the parallel discussion about new han=
dshake

flows and possibly proving them secure. If we're keeping PSK, maybe it&=
#39;s good to

keep it in mind in this discussion, since it may have different properties =
than

(EC)DHE for the proofs/security discussion.



Manuel.



_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--f46d0442713092f27e0505c52088--


From nobody Sun Oct 19 05:33:20 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F751A0164 for ; Sun, 19 Oct 2014 05:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDkl0GiStUQJ for ; Sun, 19 Oct 2014 05:33:16 -0700 (PDT)
Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9651A015B for ; Sun, 19 Oct 2014 05:33:15 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 4633E3FC8; Sun, 19 Oct 2014 15:33:12 +0300 (EEST)
Date: Sun, 19 Oct 2014 15:33:12 +0300
From: Ilari Liusvaara 
To: Eric Rescorla 
Message-ID: <20141019123312.GA13591@LK-Perkele-VII>
References: <544384C7.9030002@polarssl.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BrZXl4u1oZJD9aCz-Blifl_Pfro
Cc: Manuel =?utf-8?B?UMOpZ291cmnDqS1Hb25uYXJk?= , "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 12:33:19 -0000

On Sun, Oct 19, 2014 at 12:44:16PM +0100, Eric Rescorla wrote:
>
> On Sun, Oct 19, 2014 at 10:30 AM, Manuel Pégourié-Gonnard 
> wrote:
> 
> > Hi,
> >
> > Sorry if this was discussed previously and I missed it, but I was wondering
> > about the fate of PSK in TLS 1.3. The RSA and (EC)DH key exchanges were
> > removed
> > because they do not offer forward security. PSK does not offer FS either.
> > OTOH,
> > it has very interesting performance properties, namely it's the only key
> > exchange that does not require asymmetric crypto.
>
> Thanks for the reminder.
> 
> I've been assuming we would keep it and trying to bear it in mind as I think
> about design, but it's good to see this stated explicitly.

Some notes about PSK in TLS 1.2:

- TLS 1.2 has PSK identity hints. These are fundamentially 2RTT if used.
- PSK without identity hints is still 2RTT in TLS 1.2, but is not fundamentally
  2RTT (send identity in ClientHello).
- TLS 1.2 PSK requires application protocol to specify use of identity
  hints for those to be usable. At least one RFC does so, and another
  punts it forward (there are too many references to that RFC to scan
  quickly).
- There is also DHE-PSK in TLS 1.2. There kex data is combination of PSK
  kex data and anonDH kex data. This one is PFS.
- Then there is RSA-PSK in TLS 1.2. Too difficult to support and
  pretty much useless.
- 1RTT PSK also has some interactions with formulation of THS fix.
  Basically, one wants to force ServerHello to be always hashed.


-Ilari


From nobody Sun Oct 19 05:47:06 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8651A0164 for ; Sun, 19 Oct 2014 05:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAoGYFCdyuHs for ; Sun, 19 Oct 2014 05:47:05 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92DA1A015B for ; Sun, 19 Oct 2014 05:47:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=3LZiRydh8eX5KOJBQHqaXh0yhGjYwzoNZ86Ye/Qrd6I=;  b=HkuE8O9B3zKr6r8zCFog6wBlSyVMiAEIZEnrwfmbzAgerDM1IdaJMLFmQR+fEcQLFynmjOTxqyzB/bmvkc23/5shuIssi9K1VTdzi3WVA38jxcqaJZoIeMR/hz2ulsVLk9J8NAbRWO6sTCbaDigMyooqM4zm9C+0IhwChrKn7d8=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xfpsv-0001wA-9A; Sun, 19 Oct 2014 14:46:57 +0200
Message-ID: <5443B2C4.5050306@polarssl.org>
Date: Sun, 19 Oct 2014 14:47:00 +0200
From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ilari Liusvaara ,  Eric Rescorla 
References: <544384C7.9030002@polarssl.org>  <20141019123312.GA13591@LK-Perkele-VII>
In-Reply-To: <20141019123312.GA13591@LK-Perkele-VII>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eDIc7e0kSuW_NaNU5cWDAie-OK0
Cc: "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 12:47:06 -0000

On 19/10/2014 14:33, Ilari Liusvaara wrote:
> Some notes about PSK in TLS 1.2:
> 
> - TLS 1.2 has PSK identity hints. These are fundamentially 2RTT if used.
> - PSK without identity hints is still 2RTT in TLS 1.2, but is not fundamentally
>   2RTT (send identity in ClientHello).

I was thinking that maybe this can use the same "optimistic with fallback"
mechanism as the other key exchanges: initially the client chooses an identity
and sends it in ClientKeyShare in the same flight as the initial ClientHello. If
the server is happy with this identity, the normal 1.3 1RTT flow is used,
otherwise the server sends back an identity hint and things start over at
ClientHello.

(Only a rough idea, I didn't think about it carefully yet.)

> - There is also DHE-PSK in TLS 1.2. There kex data is combination of PSK
>   kex data and anonDH kex data. This one is PFS.

For the sake of completeness, there is also ECDHE-PSK (RFC 5489) with the same
properties.

> - Then there is RSA-PSK in TLS 1.2. Too difficult to support and
>   pretty much useless.

Apparently not widely implemented currently, btw:

https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Key_exchange_algorithms_.28alternative_key-exchanges.29

> - 1RTT PSK also has some interactions with formulation of THS fix.
>   Basically, one wants to force ServerHello to be always hashed.
> 
That's the kind of things I was hoping you (and others with the relevant
expertise) could mention!

Manuel.


From nobody Sun Oct 19 06:03:48 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886981A0179 for ; Sun, 19 Oct 2014 06:03:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lyo3WNnTiTQM for ; Sun, 19 Oct 2014 06:03:46 -0700 (PDT)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B15B1A0166 for ; Sun, 19 Oct 2014 06:03:46 -0700 (PDT)
Received: by mail-lb0-f170.google.com with SMTP id u10so2648894lbd.15 for ; Sun, 19 Oct 2014 06:03:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zjrTrfmZYrhXaWYvXFNd/vrNQRjqyFIfNkj7+Fe1+uY=; b=aQ/pvHQbucj9EFL91+QtAc//eIpj5hnY/lSbMAeLOnx4gvfP1Y018trbSMM6zIvH0T cCR2xOZghVK5aI4EWJULb3pfNFJlXdsIvAACoEn4pjvcRMqot/fiRFu/YR6RpdCb5UVs H7nhds+9QOAs4IrhY7gFyxNDYkeIXtV2gLTdifzsu2ccFrfXwZ/8woMSui/PHB4Wc2zV xtTDJs8yKM8wW+3CZm7+87lwjpH/0TAP16zL4H15boFObpqF3ZzC58slmDrOalOAI9sh 2Nbz/Oz4vjBiDm6E54QbM1wxxepMf+sNc9MNilySoDVbqEi88l2vNvxfQpTxD3nt+U+0 KQNQ==
X-Received: by 10.152.27.38 with SMTP id q6mr2352796lag.92.1413723824673; Sun, 19 Oct 2014 06:03:44 -0700 (PDT)
Received: from [172.24.248.215] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id lv10sm2203959lac.7.2014.10.19.06.03.43 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Oct 2014 06:03:44 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir 
In-Reply-To: <544384C7.9030002@polarssl.org>
Date: Sun, 19 Oct 2014 16:03:40 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com>
References: <544384C7.9030002@polarssl.org>
To: =?utf-8?Q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?= 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QZShL2dormD055Ht8PJDV43JdLE
Cc: "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 13:03:47 -0000

As Ilari said, there are ciphersuites with PSK and FS.=20

I don=E2=80=99t see what the rationale can be to allow non-PFS for PSK =
authentication, but prohibit it for certificate authentication.  That =
would imply that we can make a blanket statement that the data passed in =
PSK-authenticated sessions is inherently low-value or non-private.  I =
don=E2=80=99t think we can make that statement.

Yoav


From nobody Sun Oct 19 06:20:37 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118801A016B for ; Sun, 19 Oct 2014 06:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.138
X-Spam-Level: 
X-Spam-Status: No, score=0.138 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYKDypyd3Bd9 for ; Sun, 19 Oct 2014 06:20:31 -0700 (PDT)
Received: from hauke-m.de (hauke-m.de [IPv6:2001:41d0:8:b27b::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BF91A0197 for ; Sun, 19 Oct 2014 06:20:31 -0700 (PDT)
Received: from [IPv6:2001:470:7259:0:656f:90e1:2bfd:7a52] (unknown [IPv6:2001:470:7259:0:656f:90e1:2bfd:7a52]) by hauke-m.de (Postfix) with ESMTPSA id 2DFE020149; Sun, 19 Oct 2014 15:20:30 +0200 (CEST)
Message-ID: <5443BA9D.4090202@hauke-m.de>
Date: Sun, 19 Oct 2014 15:20:29 +0200
From: Hauke Mehrtens 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= ,  Ilari Liusvaara , Eric Rescorla 
References: <544384C7.9030002@polarssl.org>  <20141019123312.GA13591@LK-Perkele-VII> <5443B2C4.5050306@polarssl.org>
In-Reply-To: <5443B2C4.5050306@polarssl.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NeMTRgRZBQS0qdGKOV7kxbYn5nk
Cc: "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 13:20:33 -0000

On 10/19/2014 02:47 PM, Manuel Pégourié-Gonnard wrote:
> On 19/10/2014 14:33, Ilari Liusvaara wrote:
>> - Then there is RSA-PSK in TLS 1.2. Too difficult to support and
>>   pretty much useless.
> 
> Apparently not widely implemented currently, btw:
> 
> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Key_exchange_algorithms_.28alternative_key-exchanges.29

RSA-PSK is used in the protocol for doing online authentication with the
German identity card (neuer Personalausweis). This is used when a
citizen wants to authentication himself at some government website or
online shop. It is used in the communication between the eID-Client on
the consumer device and the eID-Server, the client gets a PSK to connect
to the server and the client should still be able to check the server
certificate against a trusted list. The usage is specified by the German
BSI (Federal Office for Information Security) in TR-03124 Part 1, and
other BSI TRs.

Hauke


From nobody Sun Oct 19 06:39:36 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828F91A0197 for ; Sun, 19 Oct 2014 06:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_5BJa1SYSd3 for ; Sun, 19 Oct 2014 06:39:32 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A839D1A020A for ; Sun, 19 Oct 2014 06:39:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=6c5pZww1WnsxS4BE40vEU6pxF5UOz+Hejw0vv791NqM=;  b=nQtAM+ZoR4zm/C50LROsgjZb6R8471sQdHsp6f8c9NkP2v6+zqNTfdZ8MzGqYs3E1OfgalZREJ7h+E2RfaPppoS4ymBE/74EfCstTxFUX2mje1oboxLhQsXoKow5GJQkkKzGrNvzDeUH0U9JL7/35zZxwYIOgMDjdj7i8Jug/jQ=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xfqhh-0001zx-Vh; Sun, 19 Oct 2014 15:39:26 +0200
Message-ID: <5443BF11.3090505@polarssl.org>
Date: Sun, 19 Oct 2014 15:39:29 +0200
From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Yoav Nir 
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com>
In-Reply-To: <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IXPtWqU_tcKyW6ehaqhwA1DnGsk
Cc: "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 13:39:33 -0000

On 19/10/2014 15:03, Yoav Nir wrote:
> I don’t see what the rationale can be to allow non-PFS for PSK
> authentication, but prohibit it for certificate authentication.  That would
> imply that we can make a blanket statement that the data passed in
> PSK-authenticated sessions is inherently low-value or non-private.  I don’t
> think we can make that statement.
> 
I think the point is that a non-FS PSK key exchange is orders of magnitude
cheaper in terms of computation time/power usage, RAM usage, and ROM footprint
which makes it a practical option in much more scenarios than the FS variants.

For non-PSK key exchanges however, there is some asymetric crypto going on
regardless of whether the exchange is FS or not. So while the non-FS version
might be cheaper, the cost difference is nowhere near as big as ECDHE-PSK vs PSK.

Also, while it would of course be simpler to be able to state that "TLS 1.3
offers FS" rather than "TLS 1.3 offers FS *except* for PSK", it should be noted
that there is almost no risk for PSK to be negotiated "by mistake" since the
keys need to be provisioned.

Manuel.


From nobody Sun Oct 19 06:41:47 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384B61A0248 for ; Sun, 19 Oct 2014 06:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.262
X-Spam-Level: 
X-Spam-Status: No, score=-1.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id an57WMNTeU8J for ; Sun, 19 Oct 2014 06:41:43 -0700 (PDT)
Received: from hauke-m.de (hauke-m.de [5.39.93.123]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69AB01A0242 for ; Sun, 19 Oct 2014 06:41:43 -0700 (PDT)
Received: from [IPv6:2001:470:7259:0:656f:90e1:2bfd:7a52] (unknown [IPv6:2001:470:7259:0:656f:90e1:2bfd:7a52]) by hauke-m.de (Postfix) with ESMTPSA id DD7CF20106; Sun, 19 Oct 2014 15:41:41 +0200 (CEST)
Message-ID: <5443BF95.6090406@hauke-m.de>
Date: Sun, 19 Oct 2014 15:41:41 +0200
From: Hauke Mehrtens 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Yoav Nir , =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29u?= =?UTF-8?B?bmFyZA==?= 
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com>
In-Reply-To: <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_kXPaIJThRl5eL2Bq0hbLQrSQoE
Cc: "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 13:41:44 -0000

On 10/19/2014 03:03 PM, Yoav Nir wrote:
> As Ilari said, there are ciphersuites with PSK and FS. 
> 
> I don’t see what the rationale can be to allow non-PFS for PSK authentication, but prohibit it for certificate authentication.  That would imply that we can make a blanket statement that the data passed in PSK-authenticated sessions is inherently low-value or non-private.  I don’t think we can make that statement.

For using PFS some asymmetric cryptography is needed in addition to the
symmetric cryptography and without PFS only symmetric cryptography is
needed. For normal desktop usage this does not matter, but when you want
to use TLS and DTLS on some embedded devices like Class 1 node (see
rfc7228 section 3.) with ~ 10 KiB ram and ~ 100 KiB flash and a slow CPU
(~ 10MHz) without any hardware cryptography support a DTLS handshake
without PFS is possible in under two seconds while doing a handshake
with PFS with asymmetric cryptography like ECC would take more than 10
seconds or even minutes.
In addition adding ECC also adds some more code.

I tried a DTLS handshake between two simulated MSP430X and it took 3.3
seconds for the PSK handshake using TLS_PSK_WITH_AES_128_CCM_8 and it
took 336 seconds for a handshake using the
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite on the curve secp256r1
without client authentication and 499 seconds with client
authentication. The slow part was the elliptic curve multiplication
which took 47 seconds. (my code was not very optimized and this was a
very slow CPU)

Hauke


From nobody Sun Oct 19 07:23:25 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378EE1A19EA for ; Sun, 19 Oct 2014 07:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aESlSl4pXw2b for ; Sun, 19 Oct 2014 07:23:21 -0700 (PDT)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779231A1A01 for ; Sun, 19 Oct 2014 07:23:20 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 95F256996F; Sun, 19 Oct 2014 17:23:17 +0300 (EEST)
Date: Sun, 19 Oct 2014 17:23:17 +0300
From: Ilari Liusvaara 
To: Manuel =?utf-8?B?UMOpZ291cmnDqS1Hb25uYXJk?= 
Message-ID: <20141019142317.GA21422@LK-Perkele-VII>
References: <544384C7.9030002@polarssl.org>  <20141019123312.GA13591@LK-Perkele-VII> <5443B2C4.5050306@polarssl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5443B2C4.5050306@polarssl.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xjoL3V7OaT1HpXxhUkmVPdahuJQ
Cc: "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 14:23:23 -0000

On Sun, Oct 19, 2014 at 02:47:00PM +0200, Manuel Pégourié-Gonnard wrote:
> On 19/10/2014 14:33, Ilari Liusvaara wrote:
> > Some notes about PSK in TLS 1.2:
> > 
> > - TLS 1.2 has PSK identity hints. These are fundamentially 2RTT if used.
> > - PSK without identity hints is still 2RTT in TLS 1.2, but is not fundamentally
> >   2RTT (send identity in ClientHello).
> 
> I was thinking that maybe this can use the same "optimistic with fallback"
> mechanism as the other key exchanges: initially the client chooses an identity
> and sends it in ClientKeyShare in the same flight as the initial ClientHello. If
> the server is happy with this identity, the normal 1.3 1RTT flow is used,
> otherwise the server sends back an identity hint and things start over at
> ClientHello.
> 
> (Only a rough idea, I didn't think about it carefully yet.)

Something along those lines would work, except that AFAIK client either knows
the PSK identity immediately or needs a hint from server to select it.

So one would have to stick the hint into HelloRetryRequest.

Also, would work rather nicely for DHE-PSK: If you don't know identity to
use, don't send any shares on the first round (since you will get to know
the group too on the second round).


(Well, personally I don't think HelloRetryRequest is a good idea. And
I think resetting the hash would be a very bad idea).


-Ilari


From nobody Sun Oct 19 07:35:12 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B401A1A18 for ; Sun, 19 Oct 2014 07:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS4rmYrKXBSz for ; Sun, 19 Oct 2014 07:35:06 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E2BA1A1A12 for ; Sun, 19 Oct 2014 07:35:05 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id d1so4416695wiv.12 for ; Sun, 19 Oct 2014 07:35:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IbKPWKIrP2j+wD44pgj5GbPzOaRx9KFUy9Glodl07Zs=; b=PfKw/yI14ozzB9nXO1HK9spK2wUpjVlTJ+1i1plyZTGqSaGe4fApicLPIN5mRWhNYE QNrYix3MJnfTd6Yb80EfQ2jF6aHgSH/TAorGSWZ5s5SGytvxpVVjlUIF2XNPYH2jTqgd uaPfBuHr0+TDcWDFA2tjBdNFtS2RHvgavkYuY5WjV3DuTqX1ClA7N3p4TKG1mixe+O22 MDChj9emp2ieFjdlKzUIwmLss0UZSUvL/Ea0JNaxTC/PtQ7rmLSmjAUufup8o+WJSl1t SsTy5qNaZlOsIT6MAryvqJZXAXjIix6yDBrK9q4kbkimJmjjznJwRNESWyhUsVOJFLzT /ETg==
X-Received: by 10.180.72.228 with SMTP id g4mr12786337wiv.81.1413729304757; Sun, 19 Oct 2014 07:35:04 -0700 (PDT)
Received: from [172.24.248.215] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id wk5sm8570291wjb.12.2014.10.19.07.35.03 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Oct 2014 07:35:04 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir 
In-Reply-To: <5443BF11.3090505@polarssl.org>
Date: Sun, 19 Oct 2014 17:35:02 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com>
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org>
To: =?utf-8?Q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?= 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FsrnHU8BStoqhbNsMyL7-wSjdZI
Cc: "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 14:35:07 -0000

> On Oct 19, 2014, at 4:39 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard =
 wrote:
>=20
> On 19/10/2014 15:03, Yoav Nir wrote:
>> I don=E2=80=99t see what the rationale can be to allow non-PFS for =
PSK
>> authentication, but prohibit it for certificate authentication.  That =
would
>> imply that we can make a blanket statement that the data passed in
>> PSK-authenticated sessions is inherently low-value or non-private.  I =
don=E2=80=99t
>> think we can make that statement.
>>=20
> I think the point is that a non-FS PSK key exchange is orders of =
magnitude
> cheaper in terms of computation time/power usage, RAM usage, and ROM =
footprint
> which makes it a practical option in much more scenarios than the FS =
variants.
>=20
> For non-PSK key exchanges however, there is some asymetric crypto =
going on
> regardless of whether the exchange is FS or not. So while the non-FS =
version
> might be cheaper, the cost difference is nowhere near as big as =
ECDHE-PSK vs PSK.
>=20
> Also, while it would of course be simpler to be able to state that =
"TLS 1.3
> offers FS" rather than "TLS 1.3 offers FS *except* for PSK", it should =
be noted
> that there is almost no risk for PSK to be negotiated "by mistake" =
since the
> keys need to be provisioned.

I understand. It=E2=80=99s just weird that we=E2=80=99re treating =
non-PFS like it was made from asbestos, laced with arsenic and painted =
with lead paint, while this is proposing to allow asbestos/arsenic/lead =
combo as long as it=E2=80=99s much cheaper.

I also understand that in practice, PSK ciphersuites are used only by =
small devices, whereas the web and SMTP and other things never went for =
it. But the standards don=E2=80=99t say that. They don=E2=80=99t say =
that PSK ciphersuites are especially for constrained devices. So if we =
insist that the same TLS 1.3 be used for both, and we don=E2=80=99t want =
to say that PSK is for weak security, then we should have a good story =
of why PFS is not needed for PSK uses, whereas it=E2=80=99s essential =
for all RSA uses.  If I understand the mechanism correctly, PSKs tend to =
be long-lived, and a subsequent compromise of a PSK (even if it is =
expired at the time of compromise) allows an attacker to decrypt the =
content of a TLS session.=20

So either we believe that PSK compromise is unlikely, or we believe that =
the data in a connection with a PSK ciphersuite is not future-sensitive. =
If we don=E2=80=99t, we=E2=80=99re saying that we=E2=80=99re just piling =
on security nice-to-haves because we think the users can handle them.

Yoav


From nobody Sun Oct 19 07:53:27 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A95D1A1A4B for ; Sun, 19 Oct 2014 07:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqN7ch5GoeSZ for ; Sun, 19 Oct 2014 07:53:24 -0700 (PDT)
Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4CD1A1A6F for ; Sun, 19 Oct 2014 07:53:24 -0700 (PDT)
Received: by mail-yh0-f43.google.com with SMTP id f73so1836308yha.16 for ; Sun, 19 Oct 2014 07:53:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nTHzcioROFlicjGM4jWeIr8a8pQBASODuiZDBXAT9XE=; b=YJh7z8Y4ODu/Xra0iG4kdeKX9nXexsbX/hyQvqYAC/TIfPP3t2BzJvF2UYKZyp5HGR wCOrvrPeHR2zH2E8Gd7HjmGTd7F7ntb6M06XdMD8iulvnIYp/arrXlXQRWFdA6yFiDUm zYsF7wMmY5HtXZ0xLS2no+FvzDal2FTwrofAvF3ioU6UtcQxgueSbKBg9LASiz8LPOub Ot8FOFY4nfJE4YbeyPw3ejyRqX4baqmHvomCijYo3njPcUQ/bJX7zf5HcLuXMa2P+LZp ERKG290aQvvNYEQS6qEqa2hHvJBRR3j3izgLH+o01lh0if5+BXwatJahyGYvywXvmIEZ Zm1w==
MIME-Version: 1.0
X-Received: by 10.236.38.135 with SMTP id a7mr30439283yhb.84.1413730403847; Sun, 19 Oct 2014 07:53:23 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Sun, 19 Oct 2014 07:53:23 -0700 (PDT)
In-Reply-To: <5443BF95.6090406@hauke-m.de>
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF95.6090406@hauke-m.de>
Date: Sun, 19 Oct 2014 07:53:23 -0700
Message-ID: 
From: Watson Ladd 
To: Hauke Mehrtens 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WCpaGFO0RaKoSfZMBLiMigeqtzk
Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 14:53:26 -0000

On Sun, Oct 19, 2014 at 6:41 AM, Hauke Mehrtens  wrote:
> On 10/19/2014 03:03 PM, Yoav Nir wrote:
>> As Ilari said, there are ciphersuites with PSK and FS.
>>
>> I don=E2=80=99t see what the rationale can be to allow non-PFS for PSK a=
uthentication, but prohibit it for certificate authentication.  That would =
imply that we can make a blanket statement that the data passed in PSK-auth=
enticated sessions is inherently low-value or non-private.  I don=E2=80=99t=
 think we can make that statement.
>
> For using PFS some asymmetric cryptography is needed in addition to the
> symmetric cryptography and without PFS only symmetric cryptography is
> needed. For normal desktop usage this does not matter, but when you want
> to use TLS and DTLS on some embedded devices like Class 1 node (see
> rfc7228 section 3.) with ~ 10 KiB ram and ~ 100 KiB flash and a slow CPU
> (~ 10MHz) without any hardware cryptography support a DTLS handshake
> without PFS is possible in under two seconds while doing a handshake
> with PFS with asymmetric cryptography like ECC would take more than 10
> seconds or even minutes.
> In addition adding ECC also adds some more code.
>
> I tried a DTLS handshake between two simulated MSP430X and it took 3.3
> seconds for the PSK handshake using TLS_PSK_WITH_AES_128_CCM_8 and it
> took 336 seconds for a handshake using the
> TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite on the curve secp256r1
> without client authentication and 499 seconds with client
> authentication. The slow part was the elliptic curve multiplication
> which took 47 seconds. (my code was not very optimized and this was a
> very slow CPU)

These costs are close to the costs presented in
http://discovery.csc.ncsu.edu/software/TinyECC/TR-2007-36.pdf, and so
are in the right ballpark. However, there are several reasons why
ECDHE_ECDSA is not optimal. The first is signing and validation takes
a long time, the second is that genus 2 is faster. I also think there
are some papers that get better multiplication times, but I don't
think dramatically so.

If we want, we can fix these reasons by moving to solutions like the
Triple-DH handshake. But this ends up forcing new certificates and
kinds of keys on everyone, and getting genus 2 through CFRG should be
easy, but won't be/compatibility concerns.

You seem to have a point though: embedded devices use TLS because it
can avoid public key cryptography. Removing that option has costs, and
makes TLS 1.3 less useful than otherwise. Now, would sticking with TLS
1.2 be an option?

Sincerely,
Watson Ladd

>
> Hauke
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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


From nobody Sun Oct 19 07:58:41 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6551A1A90 for ; Sun, 19 Oct 2014 07:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XH0my7jjgjlJ for ; Sun, 19 Oct 2014 07:58:38 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54CB01A016B for ; Sun, 19 Oct 2014 07:58:38 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id rd18so3293689iec.36 for ; Sun, 19 Oct 2014 07:58:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=bICcSOC7opfDYfhiVsjW47LbLQCIN7lMVog7EQ6okIg=; b=gDx7CjE2Nz+//HbJsTkGtLm5TF6vgRnvFOcLwG6xkTS16E7wNBmtNNznu29ToWDi5q 45jEOpYAb+teGdoDdaeeVERgPpMIZNFcXbrvyIOovAyhpaqrT8dVUBNIFKmSxDI0koVr HNuQ0J6cbg0RnbnMYwRuPbYqRQWD1+Dl0YqDFfcXZdv8zCLVRdZyZVPD+XRkXQSpwzKX PdxOEvJ7JI5V4NGoPyxRwwV5RtksO0W7XeMwyUNReFCVdz2B4opgkpqjtq4qUp4gRiKw yQ4YdrHA5KMfBy1j/OxRnfhxsXYUcosa3MhlFFhpVS5RHBDKM/2a8oyL5aawx8za2apJ 7z9g==
MIME-Version: 1.0
X-Received: by 10.42.21.19 with SMTP id i19mr21293143icb.37.1413730717674; Sun, 19 Oct 2014 07:58:37 -0700 (PDT)
Received: by 10.107.3.87 with HTTP; Sun, 19 Oct 2014 07:58:37 -0700 (PDT)
In-Reply-To: <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com>
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com>
Date: Sun, 19 Oct 2014 10:58:37 -0400
Message-ID: 
From: Jeffrey Walton 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ab0erNFX12k5b84_UnEhRy2sC3U
Cc: "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 14:58:39 -0000

> I understand. It=E2=80=99s just weird that we=E2=80=99re treating non-PFS=
 like it was made from asbestos, laced with arsenic and painted with lead p=
aint, while this is proposing to allow asbestos/arsenic/lead combo as long =
as it=E2=80=99s much cheaper.
>
> ...
> So either we believe that PSK compromise is unlikely, or we believe that =
the data in a connection with a PSK ciphersuite is not future-sensitive. If=
 we don=E2=80=99t, we=E2=80=99re saying that we=E2=80=99re just piling on s=
ecurity nice-to-haves because we think the users can handle them.
>
TLS-PSK provides mutual authentication and channel binding, which
addresses a major problem with RSA key transport: wrap a secret in
anybody's public key and send it (even if its the wrong server or
public key).

I'm not sure its wise to discard mutual authentication and channel
binding. They are improvements over key transport.


From nobody Sun Oct 19 08:00:42 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D901A1A99 for ; Sun, 19 Oct 2014 08:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.797
X-Spam-Level: *
X-Spam-Status: No, score=1.797 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTJPtuRHp2fL for ; Sun, 19 Oct 2014 08:00:39 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE8C1A1AA6 for ; Sun, 19 Oct 2014 08:00:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=offspark.com; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:Cc:To:From; bh=UV+Lq17eneVM/vA8KEZurm478Yj6Comve8o1mbv/1lA=;  b=aNx1GsesTH7N4hqf8FXpN+t/3lD5itIkQU3z6/zNJQKzaYlvwweUUNmcqLYdx33y4JRtp7ksiQJ8AFLt7w8WdT0K9zR94fNi+36K5duADUSJmePnQcHndMSJBJ57hMy+K2azevTHWkXGB5L1VCPygXqAWFj6yRBVgzSIkCsQXGw=;
Received: from ip54507da9.speed.planet.nl ([84.80.125.169] helo=Slimpy) by vps2.offspark.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XfryD-00026W-7o; Sun, 19 Oct 2014 17:00:33 +0200
From: "Paul Bakker" 
To: "'Yoav Nir'" , =?UTF-8?Q?'Manuel_P=C3=A9gouri=C3=A9-Gonnard'?= 
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com>
In-Reply-To: <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com>
Date: Sun, 19 Oct 2014 17:00:29 +0200
Message-ID: <00a201cfebad$704567a0$50d036e0$@offspark.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJAzLJGdr3EjQQf6MQsY+EjboZpvQFsV1vAAZBKOUMCt7H1TpsoHThg
Content-Language: nl
X-SA-Exim-Connect-IP: 84.80.125.169
X-SA-Exim-Mail-From: p.j.bakker@offspark.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1k7UTSuxghe-jLt5AUv8ghqJK4I
Cc: tls@ietf.org
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 15:00:40 -0000

> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yoav Nir
> Sent: zondag 19 oktober 2014 16:35
> I understand. It=E2=80=99s just weird that we=E2=80=99re treating =
non-PFS like it was made
> from asbestos, laced with arsenic and painted with lead paint, while =
this is
> proposing to allow asbestos/arsenic/lead combo as long as it=E2=80=99s =
much
> cheaper.

The usage scenario of PSK ciphersuites is also very different than from =
the other ciphersuites.

PSK ciphersuites are meant for closed user groups. Peers and servers are =
provisioned in advance with something they share. They often don't have =
a TTP they rely on, with certificates that can be 'demanded' by =
governments in dragnet-requests.

Regards,
Paul Bakker
PolarSSL lead maintainer


From nobody Sun Oct 19 08:06:44 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C291A1AE1 for ; Sun, 19 Oct 2014 08:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oroK5v9D53m0 for ; Sun, 19 Oct 2014 08:06:36 -0700 (PDT)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5769D1A016B for ; Sun, 19 Oct 2014 08:06:36 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id m15so3741564wgh.28 for ; Sun, 19 Oct 2014 08:06:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lexwPUJVPNRUNSiauzTVwd8nUXsYbUoA2NElUtee7E4=; b=L8l3v5JNCCo981x2Ovab/n2Vlf9Pv4kw3sv0QE12SsUFlSG/ALOr2S9oG6zVdJpa/I aNuOFXznCXQbPYprqHxoqGjG48hD9Cn/mk5rcbs86VaqZ0oqXXQfIWUvXuPfwe+QeXLn XxrHScxZkFF20QxcbxkfU5cZflb5hk9wM7wlRnQm5Fuk88iYkpNWzrDDAyj/YKgsVfpU 65i0fegPOKg9nE5xKs2RQB1iweo7OTTxucN3CINBg6fRTAKkcqH6lW0VLzRx8ffmcaWi Ap9u8n6djRU1FKBMK2dAZ0Sc2auZqFHyrvA6UD9feU3E/Sps9Qsc29Gct0dE0p6tn7pr kkVQ==
X-Gm-Message-State: ALoCoQkf6+p+HiTPtk2Y8B53MOw19fWpn2eUMW3nWp1uk1vYyZYWsbCCSvoBvr2QsWJaHqfplnkn
X-Received: by 10.194.79.201 with SMTP id l9mr25830007wjx.59.1413731194891; Sun, 19 Oct 2014 08:06:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Sun, 19 Oct 2014 08:05:53 -0700 (PDT)
In-Reply-To: <5443BA9D.4090202@hauke-m.de>
References: <544384C7.9030002@polarssl.org>  <20141019123312.GA13591@LK-Perkele-VII> <5443B2C4.5050306@polarssl.org> <5443BA9D.4090202@hauke-m.de>
From: Eric Rescorla 
Date: Sun, 19 Oct 2014 16:05:53 +0100
Message-ID: 
To: Hauke Mehrtens 
Content-Type: multipart/alternative; boundary=047d7bf0d0f6ae24bf0505c7f17c
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zlGTynnkcOpZYMMG41YaOta9TCQ
Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 15:06:41 -0000

--047d7bf0d0f6ae24bf0505c7f17c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 19, 2014 at 2:20 PM, Hauke Mehrtens  wrote:

> On 10/19/2014 02:47 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote:
> > On 19/10/2014 14:33, Ilari Liusvaara wrote:
> >> - Then there is RSA-PSK in TLS 1.2. Too difficult to support and
> >>   pretty much useless.
> >
> > Apparently not widely implemented currently, btw:
> >
> >
> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Key_excha=
nge_algorithms_.28alternative_key-exchanges.29
>
> RSA-PSK is used in the protocol for doing online authentication with the
> German identity card (neuer Personalausweis). This is used when a
> citizen wants to authentication himself at some government website or
> online shop. It is used in the communication between the eID-Client on
> the consumer device and the eID-Server, the client gets a PSK to connect
> to the server and the client should still be able to check the server
> certificate against a trusted list. The usage is specified by the German
> BSI (Federal Office for Information Security) in TR-03124 Part 1, and
> other BSI TRs.


RSA-PSK would presumably be forbidden in TLS 1.3 or the same reason
that ordinary RSA is forbidden. This shouldn't apply to DHE-PSK.

-Ekr

--047d7bf0d0f6ae24bf0505c7f17c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sun, Oct 19, 2014 at 2:20 PM, Hauke Mehrtens <<=
a href=3D"mailto:hauke@hauke-m.de" target=3D"_blank">hauke@hauke-m.de&g=
t; wrote:
On 10/1=
9/2014 02:47 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote:

> On 19/10/2014 14:33, Ilari Liusvaara wrote:

>> - Then there is RSA-PSK in TLS 1.2. Too di=
fficult to support and

>>=C2=A0 =C2=A0pretty much useless.

>

> Apparently not widely implemented currently, btw:

>

> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Key_ex=
change_algorithms_.28alternative_key-exchanges.29



RSA-PSK is used in the protocol for doing online authentication with=
 the

German identity card (neuer Personalausweis). This is used when a

citizen wants to authentication himself at some government website or

online shop. It is used in the communication between the eID-Client on

the consumer device and the eID-Server, the client gets a PSK to connect
to the server and the client should still be able to check the server

certificate against a trusted list. The usage is specified by the German
BSI (Federal Office for Information Security) in TR-03124 Part 1, and

other BSI TRs.

RSA-PSK would presumably be =
forbidden in TLS 1.3 or the same reason
that ordinary RSA is forb=
idden. This shouldn't apply to DHE-PSK.

-Ekr




--047d7bf0d0f6ae24bf0505c7f17c--


From nobody Sun Oct 19 08:08:01 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36721A1AED for ; Sun, 19 Oct 2014 08:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHUnzx0vbN4b for ; Sun, 19 Oct 2014 08:07:55 -0700 (PDT)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4D61A1AE1 for ; Sun, 19 Oct 2014 08:07:54 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id hi2so4429128wib.14 for ; Sun, 19 Oct 2014 08:07:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JMKDfvrw1BpXjfP0aOj/IIkBjlYs9CLM4z5z43g2kRo=; b=ci2mgjzlLWeauLSb1kuMlgdTxSKbtetYd6ODrez/zrX6G7ReuXZm8GMRI3AnxPf/pm dN953Uz8zE1j3lRHGRS1tRxWGcY3Ntj5Nktg9ANTyDI1S7+mrUTU879fkCmZqrb8mW/3 obpPbA4rJNEjByVRssyZCY5GYAfPPW1Vtep1jbSpEyAylhb/XvdqH3gmVyhHh+LUkpw9 Tuz/mSZObYBU2AxM06kiyjRtp35CfQN9wRzTc9zLe3T4N7Y/ucycoI2a2Xr+7DFP/ejk Kb/Ra0T6lZ0p1GCu5Nwwx2vh1xxjsp8VssDjKNP3C5FfffmAd14cUqeDiuY/IAAe8YPn gqxg==
X-Gm-Message-State: ALoCoQlokoyujy+X9bDfEkz9neDYJphVsEBSFWP6WYdo/8ow/CS1D+Ln8uNaD2WSh0ChNGo7WT07
X-Received: by 10.180.206.173 with SMTP id lp13mr12028210wic.78.1413731273686;  Sun, 19 Oct 2014 08:07:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Sun, 19 Oct 2014 08:07:13 -0700 (PDT)
In-Reply-To: <5443B2C4.5050306@polarssl.org>
References: <544384C7.9030002@polarssl.org>  <20141019123312.GA13591@LK-Perkele-VII> <5443B2C4.5050306@polarssl.org>
From: Eric Rescorla 
Date: Sun, 19 Oct 2014 16:07:13 +0100
Message-ID: 
To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= 
Content-Type: multipart/alternative; boundary=001a11c38c7c60796d0505c7f6da
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qBV_wJNfM4gLIg0-TxIx1P6NC64
Cc: "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 15:07:57 -0000

--001a11c38c7c60796d0505c7f6da
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 19, 2014 at 1:47 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard 
wrote:

> On 19/10/2014 14:33, Ilari Liusvaara wrote:
> > Some notes about PSK in TLS 1.2:
> >
> > - TLS 1.2 has PSK identity hints. These are fundamentially 2RTT if used=
.
> > - PSK without identity hints is still 2RTT in TLS 1.2, but is not
> fundamentally
> >   2RTT (send identity in ClientHello).
>
> I was thinking that maybe this can use the same "optimistic with fallback=
"
> mechanism as the other key exchanges: initially the client chooses an
> identity
> and sends it in ClientKeyShare in the same flight as the initial
> ClientHello. If
> the server is happy with this identity, the normal 1.3 1RTT flow is used,
> otherwise the server sends back an identity hint and things start over at
> ClientHello.
>
> (Only a rough idea, I didn't think about it carefully yet.)


This was my assumption as well, though I also have not worked through it.

Is there any actual use for identity hints? Under what realistic
circumstances
does a client have more then one PSK for a given server?

-Ekr


>
> > - There is also DHE-PSK in TLS 1.2. There kex data is combination of PS=
K
> >   kex data and anonDH kex data. This one is PFS.
>
> For the sake of completeness, there is also ECDHE-PSK (RFC 5489) with the
> same
> properties.
>
> > - Then there is RSA-PSK in TLS 1.2. Too difficult to support and
> >   pretty much useless.
>
> Apparently not widely implemented currently, btw:
>
>
> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Key_excha=
nge_algorithms_.28alternative_key-exchanges.29
>
> > - 1RTT PSK also has some interactions with formulation of THS fix.
> >   Basically, one wants to force ServerHello to be always hashed.
> >
> That's the kind of things I was hoping you (and others with the relevant
> expertise) could mention!
>
> Manuel.
>

--001a11c38c7c60796d0505c7f6da
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sun, Oct 19, 2014 at 1:47 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard <mpg=
@polarssl.org> wrote:
On 19/10/2014 14:33, Ilari Liusvaara wrote:

> Some notes about PSK in TLS 1.2:

>

> - TLS 1.2 has PSK identity hints. These are fundamentially 2RTT if use=
d.

> - PSK without identity hints is still 2RTT in TLS 1.2, but is not fund=
amentally

>=C2=A0 =C2=A02RTT (send identity in ClientHello).



I was thinking that maybe this can use the same "optimistic wit=
h fallback"

mechanism as the other key exchanges: initially the client chooses an ident=
ity

and sends it in ClientKeyShare in the same flight as the initial ClientHell=
o. If

the server is happy with this identity, the normal 1.3 1RTT flow is used,
otherwise the server sends back an identity hint and things start over at
ClientHello.



(Only a rough idea, I didn't think about it carefully yet.)

This was my assumption as well, though I also have not=
 worked through it.

Is there any actual use for id=
entity hints? Under what realistic circumstances
does a client ha=
ve more then one PSK for a given server?

-Ekr
=C2=A0


> - There is also DHE-PSK in TLS 1.2. There kex data is combination of P=
SK

>=C2=A0 =C2=A0kex data and anonDH kex data. This one is PFS.



For the sake of completeness, there is also ECDHE-PSK (RFC 5489) wit=
h the same

properties.



> - Then there is RSA-PSK in TLS 1.2. Too difficult to support and

>=C2=A0 =C2=A0pretty much useless.



Apparently not widely implemented currently, btw:



=
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Key_exchang=
e_algorithms_.28alternative_key-exchanges.29



> - 1RTT PSK also has some interactions with formulation of THS fix.

>=C2=A0 =C2=A0Basically, one wants to force ServerHello to be always has=
hed.

>

That's the kind of things I was hoping you (and others with the =
relevant

expertise) could mention!



Manuel.





--001a11c38c7c60796d0505c7f6da--


From nobody Sun Oct 19 08:44:04 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D9D1A1B4E for ; Sun, 19 Oct 2014 08:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkWL4d8dPVz6 for ; Sun, 19 Oct 2014 08:43:59 -0700 (PDT)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5E21A1B4D for ; Sun, 19 Oct 2014 08:43:59 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id lf12so2544826vcb.3 for ; Sun, 19 Oct 2014 08:43:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bUOAP8viiNwI5f9Y2aXQeIoy8bgtZ/qsm4SqvQH39C0=; b=fXIQZ8AXVUn+q/N0eRkp88sMFTPoRRDea0vP+hISINJ0cJldxrGJICmjzD0WLUsumc f/xZCn+CYxkHuea/Kui8ZxBDRkD0uvJNJoIeOh2J29SFmPf2Nay68slRsQWrE4G/lUeB y6JkbCIKgvPLHbO15cFsJD/DJHYLOyT4sIFVK6vfo5hFtL+vlkUCp+yOOKNaEi1hye5q qI7aIlXrNosztLrOD++A7w+bSUFTxZdbv5UGtuCN68OLxPq9UBIid+2u7+v12jkKm7Ol HPS4P+wusOb6fvonDkHSmhFK4dweeuzr8guBfcYJ2Yw3mMEWIG9bltfDjRf1Iwwhyph3 Lkyg==
MIME-Version: 1.0
X-Received: by 10.220.195.196 with SMTP id ed4mr600853vcb.65.1413733438461; Sun, 19 Oct 2014 08:43:58 -0700 (PDT)
Sender: nygren@gmail.com
Received: by 10.220.12.11 with HTTP; Sun, 19 Oct 2014 08:43:58 -0700 (PDT)
In-Reply-To: 
References: 
Date: Sun, 19 Oct 2014 11:43:58 -0400
X-Google-Sender-Auth: 0YJ3WF_DCATIkUkBvLLfML7KO58
Message-ID: 
From: Erik Nygren 
To: Eric Rescorla 
Content-Type: multipart/alternative; boundary=001a11c1c324681d7a0505c877d6
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V-rezzMj-DBMZO6aulDzcG5gAL4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 15:44:01 -0000

--001a11c1c324681d7a0505c877d6
Content-Type: text/plain; charset=UTF-8

On Sat, Oct 18, 2014 at 12:16 PM, Eric Rescorla  wrote:

> I wanted to get the discussion going on whether we need resumption [0] or
> not
> for TLS 1.3. This may be a quick discussion as I suspect the answer is
> yes, but I figure we should decide it rather than just assuming it.
>

+1 for leaving in resumption for TLS 1.3, for the reasons mentioned.

Resumption is another part of the "istlsfastyet" story that helps in selling
people on making TLS more ubiquitous, both from a performance
and cost perspective.  Dropping it at this point might harm adoption
of both TLS 1.3 as well as momentum towards TLS in general.

(Some of the other discussions on this topic focused on best
practices around session ticket key management.  If resumption
is going to stick around, then ideally there should be a BCP or similar
on sane implementation practices that do as little harm to forward secrecy
as possible.)

One other thing we may wish to consider is the relative safety
and complexity and interactions of 0RTT vs Resumption for various scenarios,
such as against replay attacks (when nonces are available and
when they aren't available).

       Erik

--001a11c1c324681d7a0505c877d6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On S=
at, Oct 18, 2014 at 12:16 PM, Eric Rescorla <ekr@rtfm.com> wrot=
e:
I wanted to get =
the discussion going on whether we need resumption [0] or not
for=
 TLS 1.3. This may be a quick discussion as I suspect the answer is
yes, but I figure we should decide it rather than just assuming it.

+1 for leaving in resumption for TL=
S 1.3, for the reasons mentioned.

Resumption is another p=
art of the "istlsfastyet" story that helps in selling
people o=
n making TLS more ubiquitous, both from a performance 
and cost perspect=
ive.=C2=A0 Dropping it at this point might harm adoption
of both TLS 1.3=
 as well as momentum towards TLS in general.

(Some of the=
 other discussions on this topic focused on best
practices around sessio=
n ticket key management.=C2=A0 If resumption
is going to stick around, t=
hen ideally there should be a BCP or similar
on sane implementation prac=
tices that do as little harm to forward secrecy 
as possible.)
=


One other thing we may wish to consider is the relative=
 safety 
and complexity and interactions of 0RTT vs Resumption for vario=
us scenarios,
such as against replay attacks (when nonces are=
 available and 
when they aren't available).

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik



<=
/div>


--001a11c1c324681d7a0505c877d6--


From nobody Sun Oct 19 10:00:21 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4501A19E4 for ; Sun, 19 Oct 2014 10:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QScSjm6RqFIX for ; Sun, 19 Oct 2014 10:00:18 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3581A0AF1 for ; Sun, 19 Oct 2014 10:00:17 -0700 (PDT)
Received: by mail-la0-f45.google.com with SMTP id q1so2794824lam.4 for ; Sun, 19 Oct 2014 10:00:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KMr1QPo5RJCERRYjfsO4x3qP/r3UV2Ojo6ncwoGMwQ4=; b=S8ZvqfWOPu/eevGwY9mpojyoO16m1bHAwNYLgv2J/97cw28+sC9KZP1cSZgRX496x2 UUUsx9cc8cqT0/qAQG2iX219jtVkyAhmP+eRky08fyNFTF43kjyZSbj2O8qoyZpcPAQ0 6lxK/s7xK8+o/gOTmqKukc7euB5Wfrk+4uHzM1JrA+ddJItcAvppaapj02MmKAFyXH9A cui/2AFx9rLYdXm36S+htvtrvyvMkYHPkkyAbVYG/1E95pEQF6Qowl+A7FcJUg8E4yhA 1GhOPXkJG6/X9YKYvpoK9wctxtiiNkNS+gJaVDIDD7XArbk7JTbzK+jRXohrR73RfoTZ aXsQ==
MIME-Version: 1.0
X-Received: by 10.152.216.200 with SMTP id os8mr3706076lac.85.1413738015966; Sun, 19 Oct 2014 10:00:15 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Sun, 19 Oct 2014 10:00:15 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9D2984@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D2984@uxcn10-5.UoA.auckland.ac.nz>
Date: Sun, 19 Oct 2014 10:00:15 -0700
Message-ID: 
From: Martin Thomson 
To: Peter Gutmann 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VIaR6yRTYvhmjE1t-Y8MGz8Sgmk
Cc: "" 
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 17:00:19 -0000

On 18 October 2014 21:12, Peter Gutmann  wrote:
>>With HTTP/2 poised to get deployed on much of the Internet,
>
> Given its embedded-device-hostile nature [...]

You'll have to justify that one.


From nobody Sun Oct 19 10:07:21 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D761A0AF8 for ; Sun, 19 Oct 2014 10:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9mIdGxHSlZb for ; Sun, 19 Oct 2014 10:07:15 -0700 (PDT)
Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1216A1A00C6 for ; Sun, 19 Oct 2014 10:07:14 -0700 (PDT)
Received: by mail-qc0-f181.google.com with SMTP id r5so2647850qcx.40 for ; Sun, 19 Oct 2014 10:07:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g0RuNDSfUl5x1elgZLfx+AIz/qjgYJVNWgucXgOuL5w=; b=Q+wnZpIK8OA+eMyOpfMIZJxxCQPfT33JNpDs2M2MivQfP3GR57AL61Z99t6d8WTLtU ncyZLyeO2F5ibugd9FTTRll8PekSWPmxiXtxePwZVWfeBlE7r+8HyRGoNLOWnDRqROt1 FIBC2IvdKaX6BuowhDhk/snQURFp3BxyzEjP4DwqtcIPE71U5ygTAnqS+6AjYgc9fW4z cFaeGxsagOWciVOFEbKi3uB6rbyBXgPDrGrRKb6BJyFOMG3vxrgRqMVayqyUTWMXvtyZ 1mWvWVsjtqkvRBNterQiHB0zV6AFP1OrxPDD+Pt2UMTLXulMVZ07LyS2TpDco4lAz01P UQjw==
X-Gm-Message-State: ALoCoQkiRpjxYlspAgVQ2he+BNnZtLIynq1POIaqJJBVwlIWaLzcGwSA61TB3VMHHLE5c28MwHch
MIME-Version: 1.0
X-Received: by 10.224.137.136 with SMTP id w8mr29455924qat.18.1413738433873; Sun, 19 Oct 2014 10:07:13 -0700 (PDT)
Received: by 10.96.166.35 with HTTP; Sun, 19 Oct 2014 10:07:13 -0700 (PDT)
X-Originating-IP: [2601:8:b300:a5:61ff:e0a3:591a:c844]
In-Reply-To: 
References:  
Date: Sun, 19 Oct 2014 10:07:13 -0700
Message-ID: 
From: Joseph Salowey 
To: Erik Nygren 
Content-Type: multipart/alternative; boundary=001a11c2d7ac281f910505c9a196
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6VB9B6SItFC7KKrWLDO9UQOW9xw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 17:07:18 -0000

--001a11c2d7ac281f910505c9a196
Content-Type: text/plain; charset=UTF-8

+1

For the reasons Peter mentioned.  There are cases where the TLS handshake
is used as an authentication mechanism such as EAP-TLS and other TLS based
EAP mechanisms.  Many deployments rely heavily on session resumption (and
session tickets).  There are also many IoT type devices that support public
key based mechanisms and would benefit from session resumption.

Joe

On Sun, Oct 19, 2014 at 8:43 AM, Erik Nygren  wrote:

> On Sat, Oct 18, 2014 at 12:16 PM, Eric Rescorla  wrote:
>
>> I wanted to get the discussion going on whether we need resumption [0] or
>> not
>> for TLS 1.3. This may be a quick discussion as I suspect the answer is
>> yes, but I figure we should decide it rather than just assuming it.
>>
>
> +1 for leaving in resumption for TLS 1.3, for the reasons mentioned.
>
> Resumption is another part of the "istlsfastyet" story that helps in
> selling
> people on making TLS more ubiquitous, both from a performance
> and cost perspective.  Dropping it at this point might harm adoption
> of both TLS 1.3 as well as momentum towards TLS in general.
>
> (Some of the other discussions on this topic focused on best
> practices around session ticket key management.  If resumption
> is going to stick around, then ideally there should be a BCP or similar
> on sane implementation practices that do as little harm to forward secrecy
> as possible.)
>
> One other thing we may wish to consider is the relative safety
> and complexity and interactions of 0RTT vs Resumption for various
> scenarios,
> such as against replay attacks (when nonces are available and
> when they aren't available).
>
>        Erik
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a11c2d7ac281f910505c9a196
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1

For the reasons Peter mentione=
d.=C2=A0 There are cases where the TLS handshake is used as an authenticati=
on mechanism such as EAP-TLS and other TLS based EAP mechanisms.=C2=A0 Many=
 deployments rely heavily on session resumption (and session tickets).=C2=
=A0 There are also many IoT type devices that support public key based mech=
anisms and would benefit from session resumption.

Joe

On Sun, =
Oct 19, 2014 at 8:43 AM, Erik Nygren <erik+ietf@nygren.org> wrote:
On Sat, Oct 18, 20=
14 at 12:16 PM, Eric Rescorla <ekr@rtfm.com> wrote:
I wanted to get the discussion g=
oing on whether we need resumption [0] or not
for TLS 1.3. This m=
ay be a quick discussion as I suspect the answer is
yes, but I fi=
gure we should decide it rather than just assuming it.

+1 for leaving in resumption for TLS 1.3, fo=
r the reasons mentioned.

Resumption is another part of th=
e "istlsfastyet" story that helps in selling
people on making =
TLS more ubiquitous, both from a performance 
and cost perspective.=C2=
=A0 Dropping it at this point might harm adoption
of both TLS 1.3 as wel=
l as momentum towards TLS in general.

(Some of the other =
discussions on this topic focused on best
practices around session ticke=
t key management.=C2=A0 If resumption
is going to stick around, then ide=
ally there should be a BCP or similar
on sane implementation practices t=
hat do as little harm to forward secrecy 
as possible.)
One other thing we may wish to consider is the relative safety=
 
and complexity and interactions of 0RTT vs Resumption for various scen=
arios,
such as against replay attacks (when nonces are availa=
ble and 
when they aren't available).

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik<=
br>




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--001a11c2d7ac281f910505c9a196--


From nobody Sun Oct 19 10:09:54 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E461A00C6 for ; Sun, 19 Oct 2014 10:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDOpawg57mRI for ; Sun, 19 Oct 2014 10:09:33 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E791A19E4 for ; Sun, 19 Oct 2014 10:09:32 -0700 (PDT)
Received: by mail-lb0-f173.google.com with SMTP id 10so2798339lbg.18 for ; Sun, 19 Oct 2014 10:09:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sX4C6jAXdJeFv2+H2xt1Qoer4F6FOeZALAdSBz/AqKw=; b=CgqAv4LYvK2NGYo2Lwg1D2zsvrthAu7d8oef/TR692dht4j+qjWeydHH9RL3ajeOSL k3PGzZYaZvDMt6m4TRtkqFdTlwSrBbZRafxj4tKlTrQexVmV2VfidjQ8bPkSNfO0X/gg VY2WdSOvpaJuyFU6iSkUsD6qM36VNHlY33yQ+/2RExJLYTIZ4aC9KPc7YDR4XaMBd/TO 5MI7mRnep3DHdbojfeMngDZVKZEGEHjpkZrsN9GxdF9qIiUfwuncihh6t7cibjz3xIX5 k6JurQbgcN0D13YhtcsZ/BxK7MSMBx7dCRuTiC6tx1TWkrFn4OMoUuXCeMJ7f2Prs2x0 YZ3w==
MIME-Version: 1.0
X-Received: by 10.112.63.70 with SMTP id e6mr3513160lbs.93.1413738571142; Sun, 19 Oct 2014 10:09:31 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Sun, 19 Oct 2014 10:09:31 -0700 (PDT)
In-Reply-To: <94F22FB7-ACA4-407C-8528-E806DFA64F54@inria.fr>
References:    <94F22FB7-ACA4-407C-8528-E806DFA64F54@inria.fr>
Date: Sun, 19 Oct 2014 10:09:31 -0700
Message-ID: 
From: Martin Thomson 
To: Karthikeyan Bhargavan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XU06C-VdRft-tSFenUZSlQk2Jr4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Refactoring client auth/re-key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 17:09:35 -0000

On 18 October 2014 23:57, Karthikeyan Bhargavan
 wrote:
> As Ilari hints, it is not enough to hash the client-server key shares int=
o
> the master secret. In a negotiated protocol like TLS, we need to add
> the DH parameters, the algorithms used to derive the keys, and the
> algorithms that the resulting key will be used with. (The crypto proofs
> typically fix these values and so they don=E2=80=99t necessarily appear i=
n the
> academic protocols.)

And it's not just that there are multiple options of algorithm.
Because there is choice involved, you need to include all the options
that were available.  Otherwise, clients are exposed to the
possibility of downgrade.

Hence the simplification of including the entire transcript still.


From nobody Sun Oct 19 10:15:48 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1591A19E7 for ; Sun, 19 Oct 2014 10:15:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gbj4q7I1EKAR for ; Sun, 19 Oct 2014 10:15:45 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F28F1A19E4 for ; Sun, 19 Oct 2014 10:15:44 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id gi9so2781405lab.21 for ; Sun, 19 Oct 2014 10:15:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dGgpIdv3AZlXA8H+xFT4TtFJ1tq61POrzTjmkR615hg=; b=ABQd7ZLva/A6Uzj4HoAagE6KTybP4/G3YR/YcVOVYWzdlXrESsFPBNp+U0f+E+9hMt 2SIoguYzKBD0NJVt4FF+BkCPadcyTBdmJBdUPmvgBF/A1iXt16Kj0DAVzpN/Zk+CJYcQ 3Dwe8loRutt7BeUE7tlRYQ6KWYII3SiuIqox7hwZHm1RFxRVdiuwrTPj/cvhkbHkw2PJ ERp0aGBS89UKkSwuo3uGyxr2v3kYlrARvhH+fXM61wK9OOck88k12uaYwMjHeojk9Vvh sCa2eOwpMTxnUDsH9NWhfbj7zMxzGevwi4T5s/jfgJKZjBbyC6XFq65c2GAqjCKH316H o9LQ==
MIME-Version: 1.0
X-Received: by 10.112.63.70 with SMTP id e6mr3543296lbs.93.1413738942765; Sun, 19 Oct 2014 10:15:42 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Sun, 19 Oct 2014 10:15:42 -0700 (PDT)
In-Reply-To: <2D0BBEAE-F6D0-4D10-AFC5-5D9885CA48BB@inria.fr>
References:    <94F22FB7-ACA4-407C-8528-E806DFA64F54@inria.fr> <20141019081551.GA12098@LK-Perkele-VII> <2D0BBEAE-F6D0-4D10-AFC5-5D9885CA48BB@inria.fr>
Date: Sun, 19 Oct 2014 10:15:42 -0700
Message-ID: 
From: Martin Thomson 
To: Karthikeyan Bhargavan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/thoQ52kfhxIPS3DRBgvTiFo3rKw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Refactoring client auth/re-key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 17:15:46 -0000

On 19 October 2014 02:58, Karthikeyan Bhargavan
 wrote:
> You=E2=80=99re right, including the peer identity applies mainly for non-=
PFS exchanges where
> the peer=E2=80=99s keycard is closely linked to its identity (RSA, PSK, a=
nd Fixed DH/ECDH)
> For DHE/ECDHE, if the client/server negotiate a known good group/curve, a=
greeing
> upon the DH params should be enough. Since, by default, the server can ch=
oose an
> arbitrary group, it seems prudent to include its identity.

I'm glad someone pointed that out; I've been meaning to.  The
session-hash draft talks about binding to identities, but that isn't
the important characteristic.

The important characteristic is that the master secret is bound to
information that can only be known to the communicating peers.  In the
non-ephemeral (legacy) mode, that means identity, but that's only
consequential.

Maybe this sentence needs to be revised:
   The Transport Layer Security (TLS) master secret is not
   cryptographically bound to important session parameters such as the
   client and server identities.


From nobody Sun Oct 19 12:55:09 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64AC1A6F47 for ; Sun, 19 Oct 2014 12:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IppB19YJc5_z for ; Sun, 19 Oct 2014 12:55:04 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5721A1B96 for ; Sun, 19 Oct 2014 12:55:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413748504; x=1445284504; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=r+peDZNPkeZKAqDg9Ka06xBjl/4N4aB9xLsEiLB1SQ4=; b=Z6Ni3C6HUDJI7IOhFXu4f3NEZFO9u3agJnuVvswld1Ud8ZtRbXVFD9Rf 42mN8pCIlDGLxIDhetwaDYL1roE9RNgNmwVvB5o0MzcpW3psLXPuvhTv/ cVacxD487LdpWoqZa+29iVpGxcXLNWwPmswijo+KekuDxzOIUl8qaJ0q2 0=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="284179269"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 20 Oct 2014 08:55:03 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 08:55:02 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Fate of resumption
Thread-Index: Ac/r1pFrysL50z3MS1eRQRzBMX1sqw==
Date: Sun, 19 Oct 2014 19:55:01 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D320C@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1xrgyeIRlpWmcgU7woPnx0bNk6k
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 19:55:08 -0000

Martin Thomson  writes:=0A=
>On 18 October 2014 21:12, Peter Gutmann  wrote:=
=0A=
>>>With HTTP/2 poised to get deployed on much of the Internet,=0A=
>>=0A=
>> Given its embedded-device-hostile nature [...]=0A=
>=0A=
>You'll have to justify that one.=0A=
=0A=
So you want something more specific than a general reference to lots of=0A=
discussion on the ietf-http-wg mailing list?  Hmm, how about this thread (o=
ne=0A=
of several that have covered the issue):=0A=
=0A=
http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0602.html=0A=
=0A=
James Snell of IBM summed it up pretty well:=0A=
=0A=
  First and foremost, it needs to be recognized that HTTP/2 has been design=
ed=0A=
  from the start to primarily meet the needs of a very specific grouping of=
=0A=
  high volume web properties and browser implementations. There is very lit=
tle=0A=
  evidence that ubiquitous use of the protocol is even a secondary=0A=
  consideration -- in fact, the "they can just keep using HTTP/1.1" mantra =
has=0A=
  been repeated quite often throughout many of the discussions here on this=
,=0A=
  usually as a way of brushing aside many of the concerns that have been=0A=
  raised. So be it. It's clear at this point that HTTP/2 is on a specific=
=0A=
  fixed path forward and that, for the kinds of use cases required by IoT,=
=0A=
  alternatives will need to be pursued.=0A=
=0A=
Peter.=


From nobody Sun Oct 19 13:49:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9751A0271 for ; Sun, 19 Oct 2014 13:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkG4rOGU7VFy for ; Sun, 19 Oct 2014 13:49:42 -0700 (PDT)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBBC31A0258 for ; Sun, 19 Oct 2014 13:49:41 -0700 (PDT)
Received: by mail-la0-f46.google.com with SMTP id gi9so2940867lab.19 for ; Sun, 19 Oct 2014 13:49:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7Tsa+ttRc81PE54pUDE+mZhArazLCDuEuLVZEp8pSIA=; b=qqCn7t5eaNex4DcgmldYnkA6INd3yqwcdWNg6cZNhpoyErI3lDEC3QYoBleD1zHE7j AKsoX86MKT677/beUjmHX/xTGkXktULyEhctdsgpGTASQEAcHj/+F9IuB3GP/HWfzfKR 0aSmQogFy6bwSjfG+U9sRi5xpxmRnjx+nFCebtgkZ0Dx4NTV6OoQXz5FsD5urfB/9Sdt Klr4spWQbcYmWFoFuo4VhUwiYVva5k43aJLXVW6977y2KqeFoivu6/8kioN70fSXp5Tn LqvPRrJbW2EifvYKxtms2EuGLnVFbaZQ3s4kLoVJ95DtoJDr+mcFGQG4d+1OwJY0L+86 4gRw==
MIME-Version: 1.0
X-Received: by 10.112.148.161 with SMTP id tt1mr23351165lbb.67.1413751780100;  Sun, 19 Oct 2014 13:49:40 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Sun, 19 Oct 2014 13:49:39 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Sun, 19 Oct 2014 13:49:39 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9D320C@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D320C@uxcn10-5.UoA.auckland.ac.nz>
Date: Sun, 19 Oct 2014 13:49:39 -0700
Message-ID: 
From: Martin Thomson 
To: Peter Gutmann 
Content-Type: multipart/alternative; boundary=047d7b3a829aa74f4e0505ccbc24
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EUTUSeOwj94IEgNufheLyKcAwuo
Cc: "" 
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 20:49:44 -0000

--047d7b3a829aa74f4e0505ccbc24
Content-Type: text/plain; charset=UTF-8

That's hearsay, not substance. I was looking for an actual technical
concern, not a replay of someone's gripes. I believe that James' angst
derives from not being permitted to arbitrarily extend the protocol in
novel ways, which has very little to do with the concern you alluded to.
On Oct 19, 2014 12:55 PM, "Peter Gutmann"  wrote:

> Martin Thomson  writes:
> >On 18 October 2014 21:12, Peter Gutmann 
> wrote:
> >>>With HTTP/2 poised to get deployed on much of the Internet,
> >>
> >> Given its embedded-device-hostile nature [...]
> >
> >You'll have to justify that one.
>
> So you want something more specific than a general reference to lots of
> discussion on the ietf-http-wg mailing list?  Hmm, how about this thread
> (one
> of several that have covered the issue):
>
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0602.html
>
> James Snell of IBM summed it up pretty well:
>
>   First and foremost, it needs to be recognized that HTTP/2 has been
> designed
>   from the start to primarily meet the needs of a very specific grouping of
>   high volume web properties and browser implementations. There is very
> little
>   evidence that ubiquitous use of the protocol is even a secondary
>   consideration -- in fact, the "they can just keep using HTTP/1.1" mantra
> has
>   been repeated quite often throughout many of the discussions here on
> this,
>   usually as a way of brushing aside many of the concerns that have been
>   raised. So be it. It's clear at this point that HTTP/2 is on a specific
>   fixed path forward and that, for the kinds of use cases required by IoT,
>   alternatives will need to be pursued.
>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7b3a829aa74f4e0505ccbc24
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


That's hearsay, not substance. I was looking for an actu=
al technical concern, not a replay of someone's gripes. I believe that =
James' angst derives from not being permitted to arbitrarily extend the=
 protocol in novel ways, which has very little to do with the concern you a=
lluded to.


On Oct 19, 2014 12:55 PM, "Peter Gutmann&qu=
ot; <pgut001@cs.auckland.ac=
.nz> wrote:
M=
artin Thomson <martin.thomso=
n@gmail.com> writes:

>On 18 October 2014 21:12, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:

>>>With HTTP/2 poised to get deployed on much of the Internet,

>>

>> Given its embedded-device-hostile nature [...]

>

>You'll have to justify that one.



So you want something more specific than a general reference to lots of

discussion on the ietf-http-wg mailing list?=C2=A0 Hmm, how about this thre=
ad (one

of several that have covered the issue):



http://lists.w3.org/Archives/Public/ietf-http-wg/2=
014AprJun/0602.html



James Snell of IBM summed it up pretty well:



=C2=A0 First and foremost, it needs to be recognized that HTTP/2 has been d=
esigned

=C2=A0 from the start to primarily meet the needs of a very specific groupi=
ng of

=C2=A0 high volume web properties and browser implementations. There is ver=
y little

=C2=A0 evidence that ubiquitous use of the protocol is even a secondary

=C2=A0 consideration -- in fact, the "they can just keep using HTTP/1.=
1" mantra has

=C2=A0 been repeated quite often throughout many of the discussions here on=
 this,

=C2=A0 usually as a way of brushing aside many of the concerns that have be=
en

=C2=A0 raised. So be it. It's clear at this point that HTTP/2 is on a s=
pecific

=C2=A0 fixed path forward and that, for the kinds of use cases required by =
IoT,

=C2=A0 alternatives will need to be pursued.



Peter.

_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls




--047d7b3a829aa74f4e0505ccbc24--


From nobody Sun Oct 19 13:54:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BECD1A034F for ; Sun, 19 Oct 2014 13:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fi8Ula1q0Vin for ; Sun, 19 Oct 2014 13:54:21 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F381A0271 for ; Sun, 19 Oct 2014 13:54:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413752060; x=1445288060; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Xh7kmShFPqPAnsTg1TjjKkvn+o7nPN/YK6kdB94+qRA=; b=nluNaiNuj7bvb2dGmavzSTyfjGFPRlKXEaK2FnRWf/qbjRInqBNK4HUj RXHUYKcTjPXln7cDQAOVCF2ioR0t70kWHhcuX/UyS0drqMWbBlnwkGtkv OSyRmgVHqH3qMWJ1jjpAa531YY10SoCsIKfmrFyg9rT+nGNA6Wli9TCL+ Y=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="284210854"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 20 Oct 2014 09:54:19 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 09:54:18 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Fate of resumption
Thread-Index: Ac/r3tmwPK/8ALUFQCSMidfNZFgzMQ==
Date: Sun, 19 Oct 2014 20:54:18 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D3300@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZVvnID6xdFAIVJIVroX78dhCUxk
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 20:54:22 -0000

Martin Thomson  writes:=0A=
=0A=
>That's hearsay, not substance. I was looking for an actual technical conce=
rn,=0A=
>not a replay of someone's gripes. =0A=
=0A=
Given that it's a discussion of real technical issues, why do you claim it'=
s=0A=
hearsay not substance?  By whatever criteria it is you're applying, almost=
=0A=
everything on the TLS list would be "hearsay, not substance".=0A=
=0A=
Peter.=0A=


From SRS0=Mujv=7K=acm.org=bmoeller@srs.kundenserver.de  Sun Oct 19 13:52:39 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596C81A6F93 for ; Sun, 19 Oct 2014 13:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSc9__JQ1_eM for ; Sun, 19 Oct 2014 13:52:37 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E22E1A0258 for ; Sun, 19 Oct 2014 13:52:36 -0700 (PDT)
Received: from mail-yh0-f46.google.com (mail-yh0-f46.google.com [209.85.213.46]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0MHG1D-1Xty671zcJ-00E6Ra; Sun, 19 Oct 2014 22:52:32 +0200
Received: by mail-yh0-f46.google.com with SMTP id f73so2073676yha.5 for ; Sun, 19 Oct 2014 13:52:31 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.110.35 with SMTP id t23mr6814732yhg.126.1413751951403; Sun, 19 Oct 2014 13:52:31 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Sun, 19 Oct 2014 13:52:31 -0700 (PDT)
Date: Sun, 19 Oct 2014 22:52:31 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1133358add31fe0505ccc627
X-Provags-ID: V02:K0:QYGR4Z4m62TUsNwfYUkD3GxMn2D6edu/9hQf52pkeoE XMPaKaAe4f7zU3Hv+yV2tzYHf5IOGcTCshqJIUMqEfazzYu675 +9hXxCD0q9QpiN90iotmguLWBn8MRHXwiLqX24EMwJ0s5IaEN/ auwdooIEjhZohqOad4Q7jcuktF5OGuxM22oxQKIvlQFskKV4un OCugGrahWnwyaC+x1YzFY9qMiP/GD+2+gqnegKfgo1ouE+nNpI gPQT30SXFTTe1CoAVqh5u3u5UKFK1BlDwr/V2qMsspUmXVyPFo 3vVGJ5YAnhGnEAbICjqdNeybRiXZMnOTqRT1eM4L7uf2eN5Uzu JPgq3Jxg6URVCX/fOnvIJs5uzmN5NH7Qxig2w+2Z9/stT3XQ/B qMzv7ugcdGOuLLKO9jtGd8JMPLHGtg4UcF3/PnrXzh+rMVFAFp iNQ6P
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mifMjm4qOMRbG5FvOk6WYIKB56g
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 20:58:21 -0000

--001a1133358add31fe0505ccc627
Content-Type: text/plain; charset=UTF-8

Andrey Jivsov :

> According to the draft, this server-side rejection is REQUIRED *if the
> client sent TLS_FALLBACK_SCSV to request it*. For the client, however, it
> is merely RECOMMENDED to send TLS_FALLBACK_SCSV in all fallback retries.
>
>

> Thinking more about it, there are two issues I see with the above: "smart
> client / dumb server" model and SHOULD for the client use of
> TLS_FALLBACK_SCSV.
>
> What was the rationale for the dumb server / smart client design?
>

The client is the one making fallback decisions anyway. Mixing that with
server-side heuristics makes it less clear what's going on (then, neither
the client nor the server could fully enforce its preferences).



> Example. Most often the servers are the custodians of the information /
> content. Servers are managed by professionals and are properly maintained.
> A server security policy might require TLS 1.1 to access the content that
> it serves. When such a server receives a ClientHello with TLS 1.0, it might
> proceed with a handshake, but display an HTML page explaining that access
> was denied due to low security, perhaps adding how to remedy the problem.
> In the end this is more secure: the same result of denying access to
> information, but with a more informative message. Neither the server nor
> the client implementations may find it appealing to code a special warning
> message specifically to flag MiT downgrade attack when TLS_FALLBACK_SCSV is
> used (e.g. to avoid false-positives), however, the server may include some
> of this information on the above-mentioned page as well, or choose to send
> inappropriate_fallback alert.
>

Well, if you think this might really happen, the scenario only confirms
that the server-side MUST is exactly right ... because if the server
includes a warning message in content it serves rather than entirely
rejecting the connection, that's well-intentioned but dangerous misbehavior
we should rather prevent. (If the server allows the downgraded handshake to
complete, the client will send secrets such as HTTP cookies even though
they may not be adequately protected.)


Currently the client has SHOULD for TLS_FALLBACK_SCSV. Why is this one not
> MUST (regardless of the server MUST or SHOULD)?
>

When you start experimental use of TLS 1.3, incompatibilities between
implementations might result in handshake failures, and silently falling
back to TLS 1.2 (without the SCSV!) could then make sense -- hence the
SHOULD (rather than MUST) for the client. (To fix interoperability,
alternatively you'd completely disable TLS 1.3 in the client, and the
fallback isn't worse than that.)



> This SHOULD for the client means that the client that implements the draft
> will use some logic to switch between cases:
> a) as if doesn't implement the draft
> b) client sends TLS_FALLBACK_SCSV with any downgraded negotiation
>
> If client does a), perhaps by interpreting network errors, POODLE
> continues to live.
>

It's a SHOULD, not MAY. I don't think omitting the SCSV when falling back
to SSL 3.0 is reasonable. (See also the draft-ietf-tls-downgrade-scsv-00
Security Considerations.)

Bodo

--001a1133358add31fe0505ccc627
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Andr=
ey Jivsov <crypto@brainhub.org>:

            
According to the draft, this server-side rejection is
              REQUIRED *if the client sent TLS_FALLBACK_SCSV to request
              it*. For the client, however, it is merely RECOMMENDED to
              send TLS_FALLBACK_SCSV in all fallback retries.
=C2=A0

    Thinking more about it, there are two issues I see with the above:
    "smart client / dumb server" model and SHOULD for the client =
use of
    TLS_FALLBACK_SCSV. 


    What was the rationale for the dumb server / smart client design?

The client is the one making fallback =
decisions anyway. Mixing that with server-side heuristics makes it less cle=
ar what's going on (then, neither the client nor the server could fully=
 enforce its preferences).

=C2=A0

    Example. Most often the servers are the custodians of the
    information / content. Servers are managed by professionals and are
    properly maintained. A server security policy might require TLS 1.1
    to access the content that it serves. When such a server receives a
    ClientHello with TLS 1.0, it might proceed with a handshake, but
    display an HTML page explaining that access was denied due to low
    security, perhaps adding how to remedy the problem. In the end this
    is more secure: the same result of denying access to information,
    but with a more informative message. Neither the server nor the
    client implementations may find it appealing to code a special
    warning message specifically to flag MiT downgrade attack when
    TLS_FALLBACK_SCSV is used (e.g. to avoid false-positives), however,
    the server may include some of this information on the
    above-mentioned page as well, or choose to send
    inappropriate_fallback alert.

Wel=
l, if you think this might really happen, the scenario only confirms that t=
he server-side MUST is exactly right ... because if the server includes a w=
arning message in content it serves rather than entirely rejecting the conn=
ection, that's well-intentioned but dangerous misbehavior we should rat=
her prevent. (If the server allows the downgraded handshake to complete, th=
e client will send secrets such as HTTP cookies even though they may not be=
 adequately protected.)


Currently the client has SHOULD =
for TLS_FALLBACK_SCSV. Why is this
    one not MUST (regardless of the server MUST or SHOULD)?

When you start experimental use of TLS 1.3, inco=
mpatibilities between implementations might result in handshake failures, a=
nd silently falling back to TLS 1.2 (without the SCSV!) could then make sen=
se -- hence the SHOULD (rather than MUST) for the client. (To fix interoper=
ability, alternatively you'd completely disable TLS 1.3 in the client, =
and the fallback isn't worse than that.)

=C2=
=A0

    This SHOULD for the client means that the client that implements the
    draft will use some logic to switch between cases:

    a) as if doesn't implement the draft

    b) client sends TLS_FALLBACK_SCSV with any downgraded negotiation

    

    If client does a), perhaps by interpreting network errors, POODLE
    continues to live. 

It's =
a SHOULD, not MAY. I don't think omitting the SCSV when falling back to=
 SSL 3.0 is reasonable. (See also the draft-ietf-tls-downgrade-scsv-00 Secu=
rity Considerations.)

Bodo



--001a1133358add31fe0505ccc627--


From nobody Sun Oct 19 16:00:57 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1AE1A066C for ; Sun, 19 Oct 2014 16:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bx4JbtbOJKO7 for ; Sun, 19 Oct 2014 16:00:48 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8C51A0366 for ; Sun, 19 Oct 2014 16:00:47 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id tp5so3689221ieb.32 for ; Sun, 19 Oct 2014 16:00:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FdqudjodQ9hGrOm7MetF0rJzxR8m4gwQeSbI47lwdzQ=; b=qutOJAyjdRMXPP1eWIc4EHCITgxZ9cXvbnRjmxBkrSyTQtMe1lSmT4Gem+cW01YoYq ieP/S30l+5BH3U81JSNrVJTDPxIvvm61hJzKGPlNnb1BZ39TLLDrM2U5NsUAYu7knr19 2ifdqML/czpIr4Y97Fa8Pz7Z/ICwCgij1cBYU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FdqudjodQ9hGrOm7MetF0rJzxR8m4gwQeSbI47lwdzQ=; b=U2Oo37++0+5iNN/cVRRJzyEzvhAycuiTVpLB9Izh1RvY444GH+PfR1fYXFZA2013tZ xxRgcn9v2bxO1aPvUty2WwA0KqCVya/dQXjVA2FUERlFa1tGxX7I97v9PR/WHVtS/OEJ Mr7x5fJ/2Ou6BMT8/6oDDagF301bEG4xObPMvpDw6QUzY2eboDhDu/4pD6uDJN75cvoh qGSL5vmPl6j96My2qXKMDxFQExZwId1WQS/EAChuOENjbf86550rQF37ITU1p6UXnFnu 5KKp3dKKnWP38TuP/zxgpKUbAyjBAvb7IuLjcbGWhdK2aNlZMTpyJQB+tZ9eHRX7W/vl JStw==
X-Gm-Message-State: ALoCoQnzq/3eG8GwE02gtyt6a/pEaQ03eIQ62/nu4aRypNtAd3/UMLyNmdj8BBft/lO8cxn9PZhr
X-Received: by 10.107.164.77 with SMTP id n74mr24692039ioe.17.1413759647460; Sun, 19 Oct 2014 16:00:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.15 with HTTP; Sun, 19 Oct 2014 16:00:27 -0700 (PDT)
In-Reply-To: 
References:  
From: Tom Ritter 
Date: Sun, 19 Oct 2014 19:00:27 -0400
Message-ID: 
To: Erik Nygren 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V0nuIYo_Av23jjZ83W7Wr4pIb-o
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 23:00:49 -0000

On 19 October 2014 11:43, Erik Nygren  wrote:
> One other thing we may wish to consider is the relative safety
> and complexity and interactions of 0RTT vs Resumption for various scenarios,
> such as against replay attacks (when nonces are available and
> when they aren't available).

++ I'm confident a Resumption-like thing will need to be present, but
I'm not clear on the difference between 0RTT and Resumption, and if we
need the latter if we have the former. (Whatever it's called.)

-tom


From nobody Mon Oct 20 03:13:59 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B5A1A7025 for ; Mon, 20 Oct 2014 03:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.612
X-Spam-Level: 
X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvlUX3UY0mMf for ; Mon, 20 Oct 2014 03:13:53 -0700 (PDT)
Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6581A701A for ; Mon, 20 Oct 2014 03:13:53 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9KADoot002377; Mon, 20 Oct 2014 06:13:50 -0400
Date: Mon, 20 Oct 2014 06:13:50 -0400 (EDT)
From: Hubert Kario 
To: Andrei Popov 
Message-ID: <2063553608.14767069.1413800030437.JavaMail.zimbra@redhat.com>
In-Reply-To: <8f805ba832b645e680bb5aba5b878265@BL2PR03MB419.namprd03.prod.outlook.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>   <7fe248e5b4374fbd8d04ff460bc3ace8@BL2PR03MB419.namprd03.prod.outlook.com> <76533ab02b644597a170cb5b76a42a99@BY2PR03MB554.namprd03.prod.outlook.com>   <8f805ba832b645e680bb5aba5b878265@BL2PR03MB419.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.5.82.6]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922)
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: AQHP6g/vkqpMmvBKoUCxL3G2jHnzlpw0TqsAgABoBICAAAgfwIAACI2AgAAH2aCAACaKgIAAAF8ggAAHRICAAAleYK+wogZE
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/J8f5BfV0PUFtqGuWKKP2Up7R3ZY
Cc: tls@ietf.org
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 10:13:55 -0000

----- Original Message -----
> From: "Andrei Popov" 
> To: "Martin Thomson" 
> Cc: tls@ietf.org
> Sent: Saturday, 18 October, 2014 3:08:20 AM
> Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Grou=
p Last Call for
> draft-ietf-tls-downgrade-scsv-00)
>=20
> Certainly a lot of implementations will keep SSL3 code around for a while=
,
> just disabled by default.
>=20
> On the client side, SCSV (not extension) is only needed if fallback to SS=
L3
> is allowed, correct? This is the very fallback that browser vendors are
> disabling right now. So the only browsers that fall back to SSL3 will be =
the
> ones without the Downgrade-SCSV support.

We don't know yet if it will be disabled in all browsers.

> On the server side, SCSV (not extension) is only needed if a) SSL3 is
> enabled, and b) the server tries to protect clients that offer TLS1.0 (no=
t
> 1.1 or 1.2) at the first connection attempt. Am I missing something?

1.3 to 1.2. Over 10% of Internet web servers are intolerant to 1.3 ClientHe=
llo

> However, a browser that implements a shiny new Downgrade-something RFC is
> unlikely to offer TLS1.0 on the first connection attempt.

Browsers maybe not (time will tell), but it got implemented in OpenSSL 0.9.=
8
which supports TLS 1.0 max.

--=20
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hkario@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic


From nobody Mon Oct 20 03:14:34 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B02D1A7113 for ; Mon, 20 Oct 2014 03:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo45QiLgeS3t for ; Mon, 20 Oct 2014 03:14:29 -0700 (PDT)
Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCA71A701A for ; Mon, 20 Oct 2014 03:14:29 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s9KA9NYv016743; Mon, 20 Oct 2014 06:09:23 -0400
Date: Mon, 20 Oct 2014 06:09:22 -0400 (EDT)
From: Hubert Kario 
To: Andrei Popov 
Message-ID: <2066781382.14765060.1413799762382.JavaMail.zimbra@redhat.com>
In-Reply-To: <1cc9c2d4409d4bf6b69a1ee21ef188d8@BL2PR03MB419.namprd03.prod.outlook.com>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D1333@uxcn10-5.UoA.auckland.ac.nz> <1cc9c2d4409d4bf6b69a1ee21ef188d8@BL2PR03MB419.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.5.82.6]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922)
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: Ac/qWbnbkqpMmvBKoUCxL3G2jHnzlgAAFCDgFZO9kNw=
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pnfBdukDi8Cr8ALll06QwExhIoQ
Cc: tls 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 10:14:32 -0000

----- Original Message -----
> From: "Andrei Popov" 
> To: "Peter Gutmann" , "" 
> Sent: Saturday, 18 October, 2014 12:34:36 AM
> Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Grou=
p Last Call for
> draft-ietf-tls-downgrade-scsv-00)
>=20
> I think about 60-90 days or so, for those clients and servers that get
> regular updates.

There are internet facing servers that support only SSLv2 and yet still get
their certificates refreshed!

I don't think we will see SSLv3 use fall into single digits in this decade.

--=20
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hkario@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic


From nobody Mon Oct 20 04:06:54 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108551A86E0 for ; Mon, 20 Oct 2014 04:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiIW8FHYy7_D for ; Mon, 20 Oct 2014 04:06:50 -0700 (PDT)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FA7D1A802D for ; Mon, 20 Oct 2014 04:06:50 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id l4so3684049lbv.12 for ; Mon, 20 Oct 2014 04:06:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+GijTatFhJMGND0DhPGDJV/u6hKUZ+PyGaLBn6pWHxU=; b=klvDyxrseeUW0z6/f1GzBKZB1Xyn/XhwmBCZzdIGEnZYpUZwU7gbK+cKQFGdb6fkq4 SIoVfFElTaQPovEofs02kf6DjXbAgjiM6WZmekj7tVtS8v7WIrpWfmrgu82NNf4JjrAw rE63kcQ3GacYCSoy3Ib7xrdAzCYMNKE7R7m3W7rQqB7jhMGXiw44wsdPiWtuXFfNLBUl MGjC2G4Kse1saVTG/WsLjJp0QKm+JahgWtaKwiIx2T8YzxcDPTtBODWv7GkvVoiHxGxt oZfQzvA5bA7uxrXK6G7wnLMmBdIhCREx65BVTLex9E81qt2zBdonzBHBF6Q4ie+IeDFA ZAzw==
MIME-Version: 1.0
X-Received: by 10.152.23.3 with SMTP id i3mr2274598laf.53.1413803208718; Mon, 20 Oct 2014 04:06:48 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Mon, 20 Oct 2014 04:06:48 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9D3300@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D3300@uxcn10-5.UoA.auckland.ac.nz>
Date: Mon, 20 Oct 2014 04:06:48 -0700
Message-ID: 
From: Martin Thomson 
To: Peter Gutmann 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Btn1pwo5M1-FCKV6X9SqAe6HeuM
Cc: "" 
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 11:06:52 -0000

On 19 October 2014 13:54, Peter Gutmann  wrote:
> Given that it's a discussion of real technical issues, why do you claim it's
> hearsay not substance?  By whatever criteria it is you're applying, almost
> everything on the TLS list would be "hearsay, not substance".

It's a bald assertion.  What evidence is offered in favour of the argument?

It's fine to use that as evidence that not everyone is happy with the
outcome.  But I was hoping for something more concrete, like a
suggestion that header compression was too memory or CPU intensive,
anything really.


From nobody Mon Oct 20 04:47:57 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4F11A86EC for ; Mon, 20 Oct 2014 04:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiwX4JO_Qxs5 for ; Mon, 20 Oct 2014 04:47:54 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7251A6FED for ; Mon, 20 Oct 2014 04:47:54 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9KBlpoA027076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 20 Oct 2014 07:47:51 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9KBlnCm007186 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 07:47:50 -0400
Message-ID: <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Bodo Moeller 
Date: Mon, 20 Oct 2014 13:47:48 +0200
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com> 
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7z3FuD2xxcOmZUuLW1wuI_bDJm8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 11:47:56 -0000

On Thu, 2014-10-16 at 16:34 +0200, Bodo Moeller wrote:

> When writing the TLS_FALLBACK_SCSV specification, I was thus aiming to
> keep it simple enough so that implementors would be extremely unlikely
> to get it wrong (at least once there's some base deployment of clients
> and servers so that basic interoperability tests will immediately
> expose large classes of potential bugs, which should by now be the
> case). Do you seriously think that implementors might end up sending
> TLS_FALLBACK_SCVS unconditionally? If so, do you think that those
> implementors would be capable of avoiding other more subtle bugs, and
> overall to create a mostly usable and possibly even reasonably secure
> product? (I can't help thinking that if a client is *that* broken,
> we'd probably be doing its users a favor by having all handshakes
> fail.)
> More importantly, if there were no fallback retries and thus no need
> for TLS_FALLBACK_SCSV, how could that *possibly* make it *easier* to
> deploy TLS 1.3 given that buggy peers may be around?

I pretty much understand your argumentation, but I think that the
argument for the SCSV boils down on whether we want to keep the insecure
browser fallback mechanism for long. I believe that we shouldn't, and
this is the reason I don't like this draft; it gives legitimacy to an
out-of-standard insecure protocol fallback mechanism.

Indeed, there is an arguments to keep that mechanism, as there are still
some TLS 1.3 intolerant servers. But instead of prolonging the life of
such an insecure mechanism wouldn't it make sense to fix those broken
servers instead; e.g., by peer pressure by documenting the
implementations that are not TLS 1.3-ready in [0]?

[0]. http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

regards,
Nikos




From nobody Mon Oct 20 04:53:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81281A86F4 for ; Mon, 20 Oct 2014 04:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmR02YygDurh for ; Mon, 20 Oct 2014 04:53:21 -0700 (PDT)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1084F1A8034 for ; Mon, 20 Oct 2014 04:53:20 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id b6so3742480lbj.3 for ; Mon, 20 Oct 2014 04:53:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tQ6vvN/L9JScHFcjpeUW+fijw/Ufyr8KlHLBKBhGPbk=; b=HDXmUiLqfeQCCZ7RIjllFOvKk1X8CZB4oZ77pIhBpvxO1k2R7TomVbPH7k7aczJRhC /J7AazCxuT3J+L4GZss/KS70lgGD96/hgMu7wNYqcyQUh2ps6MhE46Imd5x1KktyRQR8 RoB0mIJZSnP5gkbA15IP80zka5aJV7dGov2et6uHVi8aDGI0vSVTmciAplUrYQ/xC9eP tE9v24f+Z+VJqrao7hJnAjaoZbbjCXapeOXNzviPPBfFa8zwfxmeoqRDjS8zY57CG6YH dNIYVR6fCcYmtZSgjW+A0Cygx5QZLBhqNU5j8IdVL/F1inKTV1mket5IwoMWVReUof+9 5NYA==
MIME-Version: 1.0
X-Received: by 10.113.5.7 with SMTP id ci7mr27353261lbd.9.1413805998839; Mon, 20 Oct 2014 04:53:18 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Mon, 20 Oct 2014 04:53:18 -0700 (PDT)
In-Reply-To: <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>  <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com>
Date: Mon, 20 Oct 2014 04:53:18 -0700
Message-ID: 
From: Martin Thomson 
To: Nikos Mavrogiannopoulos 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/i4Pma-BulG9gkFOKu4JgF60CZ2A
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 11:53:23 -0000

On 20 October 2014 04:47, Nikos Mavrogiannopoulos  wrote:
> Indeed, there is an arguments to keep that mechanism, as there are still
> some TLS 1.3 intolerant servers. But instead of prolonging the life of
> such an insecure mechanism wouldn't it make sense to fix those broken
> servers instead; e.g., by peer pressure by documenting the
> implementations that are not TLS 1.3-ready in [0]?

I think that we should do that, but as a practical matter, I suspect
that we'll be stuck with some amount of fallback for a while yet.  I
find the TLS 1.3 intolerance numbers pretty alarming in this regard;
even with rapid improvement, I doubt it will go away quickly.


From nobody Mon Oct 20 04:53:53 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4F61A86FA for ; Mon, 20 Oct 2014 04:53:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8nMTPIvhKYk for ; Mon, 20 Oct 2014 04:53:51 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA271A86F9 for ; Mon, 20 Oct 2014 04:53:50 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id ge10so3725727lab.24 for ; Mon, 20 Oct 2014 04:53:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gsawA3oLVa2v5jEsEk44MlXEvArDIUrzzuTgObOZQSk=; b=wE5rcQuazmSe48zuIb9em2IygAtxumSuTUwJOhdS1m7G+yi1jjJ3hNDL1Skoyd9T7v m2FHR3k87ctzMZ8nOpS1khUKhSiDiD9AGTninr/cHbNKsdAUaXXhwGTI3jNGGqWwYObq o08ogVWIZiQk96H2aQZ0XC2L8s6wRlqxwNIzn2XFLQiMQYG1rH+DGJZpPM8oGL/gIJJ0 mI1f6corPjafgZRUA6Ss/XmHm/hCUHVCTlRmvLzHy0gPjHtMBAJT72Swg7x41kB5+55B EVSiT0Z/muwa+MzBggNgCOB4lQ4dFbBpX1/3TgnF4UYPw1Oilt0R1pycs5BKrV/D2dYK EqqQ==
MIME-Version: 1.0
X-Received: by 10.152.216.200 with SMTP id os8mr3069569lac.85.1413806028940; Mon, 20 Oct 2014 04:53:48 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Mon, 20 Oct 2014 04:53:48 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>  <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com> 
Date: Mon, 20 Oct 2014 04:53:48 -0700
Message-ID: 
From: Martin Thomson 
To: Nikos Mavrogiannopoulos 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ma-2sN9TsuFf7sWniyic_pr92KQ
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 11:53:52 -0000

On 20 October 2014 04:53, Martin Thomson  wrote:
> On 20 October 2014 04:47, Nikos Mavrogiannopoulos  wrote:
>> Indeed, there is an arguments to keep that mechanism, as there are still
>> some TLS 1.3 intolerant servers. But instead of prolonging the life of
>> such an insecure mechanism wouldn't it make sense to fix those broken
>> servers instead; e.g., by peer pressure by documenting the
>> implementations that are not TLS 1.3-ready in [0]?
>
> I think that we should do that, but as a practical matter, I suspect
> that we'll be stuck with some amount of fallback for a while yet.  I
> find the TLS 1.3 intolerance numbers pretty alarming in this regard;
> even with rapid improvement, I doubt it will go away quickly.

...enough.


From nobody Mon Oct 20 05:13:14 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC391A7D84 for ; Mon, 20 Oct 2014 05:13:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.968
X-Spam-Level: 
X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaiDE3Ir0K0r for ; Mon, 20 Oct 2014 05:13:10 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E68411A7035 for ; Mon, 20 Oct 2014 05:13:09 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 35CA910224008; Mon, 20 Oct 2014 05:13:09 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 20 Oct 2014 05:13:09 -0700 (PDT)
Message-ID: <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net>
In-Reply-To: <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com>
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com>
Date: Mon, 20 Oct 2014 05:13:09 -0700 (PDT)
From: "Dan Harkins" 
To: "Yoav Nir" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8lEx7TuttykIy5uyZCm6G9zeZfk
Cc: Manuel =?iso-8859-1?Q?P=C3=A9gouri=C3=A9-Gonnard?= , tls@ietf.org
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 12:13:12 -0000

On Sun, October 19, 2014 7:35 am, Yoav Nir wrote:
>
> I also understand that in practice, PSK ciphersuites are used only by
> small devices, whereas the web and SMTP and other things never went for
> it. But the standards don’t say that. They don’t say that PSK
> ciphersuites are especially for constrained devices. So if we insist that
> the same TLS 1.3 be used for both, and we don’t want to say that PSK is
> for weak security, then we should have a good story of why PFS is not
> needed for PSK uses, whereas it’s essential for all RSA uses.  If I
> understand the mechanism correctly, PSKs tend to be long-lived, and a
> subsequent compromise of a PSK (even if it is expired at the time of
> compromise) allows an attacker to decrypt the content of a TLS session.

  The non-PFS PSK ciphersuites are no different than the widely
discredited, and easily cracked, WPA-PSK mode of WiFi security. It would
be a really bad idea to continue with these ciphersuites in TLS 1.3. But the
issue is not just PFS (or the lack of it), it's that PSK ciphersuites are
susceptible to dictionary attack.

> So either we believe that PSK compromise is unlikely, or we believe that
> the data in a connection with a PSK ciphersuite is not future-sensitive.
> If we don’t, we’re saying that we’re just piling on security
> nice-to-haves because we think the users can handle them.

  There's no way that the protocol can be defined to justify that belief.
What you're talking about is how people end up using the protocol and
that is entirely out of the power of this WG. What we can do is to make
TLS be as _misuse resistant_ as possible. And to do that we should not
allow PSKs in TLS 1.3 unless they are used in a PAKE.

  By the way, I'm surprised that no one is expressing outrageous outrage
at the lack of a security proof for PSK ciphersuites.

  regards,

  Dan.



From nobody Mon Oct 20 05:21:48 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3C51A86F8 for ; Mon, 20 Oct 2014 05:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-4Ot_O9fT2k for ; Mon, 20 Oct 2014 05:21:42 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A651A86DD for ; Mon, 20 Oct 2014 05:21:42 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9KCLfEF004618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 20 Oct 2014 08:21:41 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9KCLdL9011522 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 08:21:40 -0400
Message-ID: <1413807699.2597.14.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Bodo Moeller 
Date: Mon, 20 Oct 2014 14:21:39 +0200
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>  <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com> 
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/y71Ulg0WcTa15zfNHRMlqSb8xRM
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 12:21:45 -0000

On Mon, 2014-10-20 at 14:13 +0200, Bodo Moeller wrote:
> Nikos Mavrogiannopoulos :
> 
>         Indeed, there is an arguments to keep that mechanism, as there
>         are still
>         some TLS 1.3 intolerant servers. But instead of prolonging the
>         life of
>         such an insecure mechanism wouldn't it make sense to fix those
>         broken
>         servers instead; e.g., by peer pressure by documenting the
>         implementations that are not TLS 1.3-ready in [0]?

> It certainly makes sense to fix those broken servers. I disagree with
> fixing them *instead* of deploying TLS_FALLBACK_SCSV; I think that's a
> false dichotomy. If you are willing to stop fallback retries in the
> client products that Red Hat distributes right now, great (do you?),
> but clearly not everyone is willing to take that step at this time.
> Until it has happened, clients already can benefit from
> TLS_FALLBACK_SCSV.

I disagree. It is a correct dichotomy :) If the servers are fixed, there
is no use for the fallback SCSV, as clients would not need to perform
the insecure fallback.

As of the argument that clients would be protected from the SCSV, that
only works if both the clients _and_ the servers are updated to support
the fallback SCSV. Why is that step necessary, if we can instead fix the
clients and the servers to properly negotiate TLS?

regards,
Nikos




From SRS0=BZpw=7L=acm.org=bmoeller@srs.kundenserver.de  Mon Oct 20 05:13:15 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183731A86EF for ; Mon, 20 Oct 2014 05:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dx6jlNdojMkB for ; Mon, 20 Oct 2014 05:13:14 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9EBF1A7035 for ; Mon, 20 Oct 2014 05:13:13 -0700 (PDT)
Received: from mail-yh0-f49.google.com (mail-yh0-f49.google.com [209.85.213.49]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0LoJRp-1YM6IB3Pkf-00gDEU; Mon, 20 Oct 2014 14:13:11 +0200
Received: by mail-yh0-f49.google.com with SMTP id a41so2958902yho.8 for ; Mon, 20 Oct 2014 05:13:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.108.164 with SMTP id q24mr3201827yhg.131.1413807187688;  Mon, 20 Oct 2014 05:13:07 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Mon, 20 Oct 2014 05:13:07 -0700 (PDT)
In-Reply-To: <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>  <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com>
Date: Mon, 20 Oct 2014 14:13:07 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c1c9fc3404360505d9a32a
X-Provags-ID: V02:K0:Pr0wgq5nO0WwhiL9TV9DQW8PVLYUajbzEhoUfLDhJZh jlAmS9vlcUYxzArlkvgn+YpJ+1UqAJIvwahSdWU0zghFHLLemP KbdM2cFz/nJ1VblTBLPzXuVcjdqMBGZkEi6fpfeVwoWKhZJWdD 68StqvJgisCSDuqI8bxCPnDxJyBJiR/FSFMZ9UGMpZljb6zvOa 8uTD782HMoh/asrnp1yp9Weww3tG6uGnwrNgsXqQ7Fdu9uUiHQ 1ys9OGnFC+2jT2LIm8DsRwxL2xDD4hB+9u5Q+OxXTpAXdgcfOH rqZj4oIEZxX9suKe4F6AE9gdFXM2IusnW/ND8Zxp9SULGkfRFc 49gtdMF2DLxClgZC33ROGDH+AuiBEY9oBoHPMBDldkUeEQN1rw LGsomySTb9WhJFgQMl4YcDvM1VdXYDNIeSMp/bazRAC3TYxT9c 9EyJP
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ma10AuJiqoDk4GFzRLsz1WqkUSk
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 12:26:48 -0000

--001a11c1c9fc3404360505d9a32a
Content-Type: text/plain; charset=UTF-8

Nikos Mavrogiannopoulos :

Indeed, there is an arguments to keep that mechanism, as there are still
> some TLS 1.3 intolerant servers. But instead of prolonging the life of
> such an insecure mechanism wouldn't it make sense to fix those broken
> servers instead; e.g., by peer pressure by documenting the
> implementations that are not TLS 1.3-ready in [0]?
>

It certainly makes sense to fix those broken servers. I disagree with
fixing them *instead* of deploying TLS_FALLBACK_SCSV; I think that's a
false dichotomy. If you are willing to stop fallback retries in the client
products that Red Hat distributes right now, great (do you?), but clearly
not everyone is willing to take that step at this time. Until it has
happened, clients already can benefit from TLS_FALLBACK_SCSV.

Bodo

--001a11c1c9fc3404360505d9a32a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Niko=
s Mavrogiannopoulos <nmav@redhat.com>:


Indeed, there is an arguments to keep that mechanism, as there are still
some TLS 1.3 intolerant servers. But instead of prolonging the life of

such an insecure mechanism wouldn't it make sense to fix those broken
servers instead; e.g., by peer pressure by documenting the

implementations that are not TLS 1.3-ready in [0]?
It certainly makes sense to fix those broken servers. I disagre=
e with fixing them *instead* of deploying TLS_FALLBACK_SCSV; I think that&#=
39;s a false dichotomy. If you are willing to stop fallback retries in the =
client products that Red Hat distributes right now, great (do you?), but cl=
early not everyone is willing to take that step at this time. Until it has =
happened, clients already can benefit from TLS_FALLBACK_SCSV.
Bodo




--001a11c1c9fc3404360505d9a32a--


From nobody Mon Oct 20 05:30:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9901A86E5 for ; Mon, 20 Oct 2014 05:30:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd2VLTFE7Vay for ; Mon, 20 Oct 2014 05:30:35 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B401A8028 for ; Mon, 20 Oct 2014 05:30:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=iNYDtIvCmu0aA8zn7BHR6MTs1A416OIh2OSCypidp/M=;  b=dIdmOcIPHZh2OkSA9KdWRC1/tZYyeNJHUv9L4NWVoSfqO3z2JSLfYs6ilhjRMWVfN2OnxKLsfvk5AzwyazxR509s+4hCzkQJKn/m3mU1CTk7gfIqeQ36LnH2JDgVoMfhhwp9KKeeLAqPksi+8gxJYEZo1dR4rnjdFTUzt7qwoX8=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgC6W-0003T6-TH; Mon, 20 Oct 2014 14:30:29 +0200
Message-ID: <54450068.5020101@polarssl.org>
Date: Mon, 20 Oct 2014 14:30:32 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" ,  "" 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
In-Reply-To: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5xhQy9xntnTBDqeoi94ly4UNH60
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 12:30:37 -0000

On 26/09/2014 06:00, Joseph Salowey (jsalowey) wrote:
> This is an announcement for the working group last call for
> draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your
> comments to the list by Friday, October 17, 2014.
> 
Just to mention that I just implemented this. As expected (since it's one of the
design goals of the draft), it was very easy.

The only problem I ran into was an interop issue with OpenSSL, which apparently
does not like it if the SCSV appears before the actual ciphersuites in the
ciphersuite list. If the intention of the draft was that the SCSV MUST be placed
after the actual ciphersuites, it would be good to state so using normative
language, rather than the current one which doesn't look normative:

                                     (Since the cipher suite list in the
      ClientHello is ordered by preference, with the client's favorite
      choice first, signaling cipher suite values will generally appear
      after all cipher suites that the client actually intends to
      negotiate.)

Otherwise, it should probably be clarified that servers MUST recognize the SCSV
at any position in the ciphersuite list, which is my preferred option. (It can
be combined with a "clients SHOULD place it after actual ciphersuites", I have
no opinion on that one).

Manuel.


From nobody Mon Oct 20 05:36:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCDF1A8700 for ; Mon, 20 Oct 2014 05:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtRxLJwE19Zx for ; Mon, 20 Oct 2014 05:36:32 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566CC1A86F8 for ; Mon, 20 Oct 2014 05:36:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413808592; x=1445344592; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=YQbldYAgBJAIEdFKDs5pyYrVlWIu0Es97ln2pjX97AY=; b=pal0/o7T6jfr1y89jUQlMZ9Aopqz/fNC2hNBCX0pVDwsxZ2upXpPM0X7 rvJbpOZj+OMek7LfW7X+mI+yBs8NELmOFsg5pZTmqB8PL2itoy/6Qtwp/ F9LZS7ipN/W3AasY+1itSGyCWfQKLjz1MoIOKWys6ZPd1CQowGtsVTnE3 U=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="284431400"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Oct 2014 01:36:30 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 01:36:30 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Fate of resumption
Thread-Index: Ac/sYnjxw/svcTt/R+KJ7pgXsoT0Uw==
Date: Mon, 20 Oct 2014 12:36:29 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D3990@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/st7a4M6rkpVbtzdbmPSmUA7oHmQ
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 12:36:37 -0000

Martin Thomson  writes:=0A=
=0A=
>But I was hoping for something more concrete, like a suggestion that heade=
r=0A=
>compression was too memory or CPU intensive, anything really.=0A=
=0A=
I'm assuming from this comment that you haven't actually bothered reading a=
ny=0A=
of the numerous discussions that have occurred on the httpbis mailing list=
=0A=
that cover this, in which case continuing this exchange is just wasting=0A=
people's time.  In that case I'll (try and) make this my last message on th=
e=0A=
topic and let people get back to real work.=0A=
=0A=
Peter.=0A=


From nobody Mon Oct 20 05:40:06 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6D21A870F for ; Mon, 20 Oct 2014 05:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oen2Z-d9qZBZ for ; Mon, 20 Oct 2014 05:40:04 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0881A8709 for ; Mon, 20 Oct 2014 05:40:03 -0700 (PDT)
Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0MI8Ug-1XhrDS3ktS-003rvC; Mon, 20 Oct 2014 14:40:01 +0200
Received: by mail-yh0-f44.google.com with SMTP id i57so3030308yha.17 for ; Mon, 20 Oct 2014 05:39:59 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.203.114 with SMTP id e78mr39513833yho.47.1413808799662;  Mon, 20 Oct 2014 05:39:59 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Mon, 20 Oct 2014 05:39:59 -0700 (PDT)
In-Reply-To: <1413807699.2597.14.camel@dhcp-2-127.brq.redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>  <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com>  <1413807699.2597.14.camel@dhcp-2-127.brq.redhat.com>
Date: Mon, 20 Oct 2014 14:39:59 +0200
Message-ID: 
From: Bodo Moeller 
To: Nikos Mavrogiannopoulos 
Content-Type: multipart/alternative; boundary=089e0158c7c448ca170505da0333
X-Provags-ID: V02:K0:qh7FZnHIWnIYDwtwdpb3K7TokZuw17zs41s/hd1rufn vT65foF6lnlhE8KtMWqmi/lmsOE2CaMZp4YzUwanUKWGZEFS82 7mI6wFM0Z4F10ZNF4Tp1BbTs7CvnsJQWE6WJz0IR3TVFsSTAit UzYSWTbpYenSntJPmToCOwFARnxujHKjFkOYbo3CXLnJIptGdA 13fW1c4InJvM0SORinjEMq5CqqZ3MQVDmK+nqiw6mK60st+6RT asoq1zwLaUxy2FJJgxA0wCuYCGYTJj0hBZ72LLS8Wzoi6DBqYu KUUqr6O93JdL23/Ah6KaulDMehhMzBs3/p88OIrkrpGrRZy+IM 0T9hyDexNrhwe+pTxuPjxCSAtiraMgPxQLrpZIEk3MSg+gUtz5 iI7Fse5nyDibqOZfMDmSe7lEE7b16WCnGXiVrs8PmfGmqs0mK/ hQoi/
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/r_LG602NjYK6JFcGSLfb1Gbk2aw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 12:40:05 -0000

--089e0158c7c448ca170505da0333
Content-Type: text/plain; charset=UTF-8

Nikos Mavrogiannopoulos :

> It certainly makes sense to fix those broken servers. I disagree with
> > fixing them *instead* of deploying TLS_FALLBACK_SCSV; I think that's a
> > false dichotomy. If you are willing to stop fallback retries in the
> > client products that Red Hat distributes right now, great (do you?),
> > but clearly not everyone is willing to take that step at this time.
> > Until it has happened, clients already can benefit from
> > TLS_FALLBACK_SCSV.
>


> I disagree. It is a correct dichotomy :) If the servers are fixed, there
> is no use for the fallback SCSV, as clients would not need to perform
> the insecure fallback.
>

True, but clearly they aren't fixed *now*, and more importantly, various
current clients *do* still find it necessary to use fallback retries to
work with such servers.

I agree that TLS_FALLBACK_SCSV is hypothetically pointless :-)

In reality, though, it does serve a purpose.


As of the argument that clients would be protected from the SCSV, that
> only works if both the clients _and_ the servers are updated to support
> the fallback SCSV. Why is that step necessary, if we can instead fix the
> clients and the servers to properly negotiate TLS?


Using the SCSV already helps if *some* servers have been updated to support
it: connections to these servers, at least, will be more secure. For other
servers, you get what you have now.

Disabling fallback retries provides more encompassing protection, but
before you can take that step, you *first* need to fix the servers (that
is, all servers you'd still want to be able to connect to).

If you want to protect information in practice, it's not sufficient to be
confident to have a solution at some point in the future. It also matters
when you can deploy it. There's nothing that blocks you from deploying
TLS_FALLBACK_SCSV -- the broken servers will be just as broken, but you
don't depend on them getting fixed to be able to protect your connections
to servers that do support TLS_FALLBACK_SCSV.

Bodo

--089e0158c7c448ca170505da0333
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Niko=
s Mavrogiannopoulos <nmav@redhat.com>:


> It certainly makes sense to fix those broken servers. I disagree with<=
br>
> fixing them *instead* of deploying TLS_FALLBACK_SCSV; I think that'=
;s a

> false dichotomy. If you are willing to stop fallback retries in the
> client products that Red Hat distributes right now, great (do you?),
> but clearly not everyone is willing to take that step at this time.
> Until it has happened, clients already can benefit from

> TLS_FALLBACK_SCSV.
=C2=A0


I disagree. It is a correct dichotomy :) If the servers are fix=
ed, there

is no use for the fallback SCSV, as clients would not need to perform

the insecure fallback.

True, but clearl=
y they aren't fixed *now*, and more importantly, various current client=
s *do* still find it necessary to use fallback retries to work with such se=
rvers.

I agree that=C2=A0TLS_FALLBACK_SCSV is hypo=
thetically pointless :-)

In reality, though, it do=
es serve a purpose.



As of the argument that clients would be protected from the SCSV, that

only works if both the clients _and_ the servers are updated to support

the fallback SCSV. Why is that step necessary, if we can instead fix the
clients and the servers to properly negotiate TLS?

Using the SCSV already helps if *some* servers have been updated to=
 support it: connections to these servers, at least, will be more secure. F=
or other servers, you get what you have now.

Disab=
ling fallback retries provides more encompassing protection, but before you=
 can take that step, you *first* need to fix the servers (that is, all serv=
ers you'd still want to be able to connect to).

If you want to protect information in practice, it's not sufficient t=
o be confident to have a solution at some point in the future. It also matt=
ers when you can deploy it. There's nothing that blocks you from deploy=
ing TLS_FALLBACK_SCSV -- the broken servers will be just as broken, but you=
 don't depend on them getting fixed to be able to protect your connecti=
ons to servers that do support TLS_FALLBACK_SCSV.

=
Bodo



--089e0158c7c448ca170505da0333--


From nobody Mon Oct 20 05:51:59 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8581A871E for ; Mon, 20 Oct 2014 05:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.638
X-Spam-Level: 
X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfv2p-QIDN51 for ; Mon, 20 Oct 2014 05:51:57 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77E91A870B for ; Mon, 20 Oct 2014 05:51:56 -0700 (PDT)
Received: from mail-yh0-f41.google.com (mail-yh0-f41.google.com [209.85.213.41]) by mrelayeu.kundenserver.de (node=mreue007) with ESMTP (Nemesis) id 0LbTPL-1YQqyv3Bu7-00lCiI; Mon, 20 Oct 2014 14:51:55 +0200
Received: by mail-yh0-f41.google.com with SMTP id i57so3083761yha.28 for ; Mon, 20 Oct 2014 05:51:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.110.35 with SMTP id t23mr4375743yhg.126.1413809512557; Mon, 20 Oct 2014 05:51:52 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Mon, 20 Oct 2014 05:51:52 -0700 (PDT)
In-Reply-To: <54450068.5020101@polarssl.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <54450068.5020101@polarssl.org>
Date: Mon, 20 Oct 2014 14:51:52 +0200
Message-ID: 
From: Bodo Moeller 
To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= 
Content-Type: multipart/alternative; boundary=001a1133358ac6b62a0505da2dc9
X-Provags-ID: V02:K0:GcNap0wpQmlUmPbIPpG4tg0QLLF8JcLwvmF5baIWCYL DyF9qW8B9Ao4aMUdGZpahp1W87Kn3EWTGybu3KbRaVjbDfagzG BJq3mqi7+Rt46/tLSlQssFpBWG0iWPtoBDZcIX72b+llv/DviN z8M7WMaCxBvdJClMt55ztUdQkk1DZZpE2n4E7mLf9C4Cg6koes YRbzMaJb30EJBrZnk4lCcqdO5fj5NmtxsO3KS7m3yLBQYVvqWi tnYGr4feRbxtz/yJE80C0vLftRaDAsMO+3Z8iWcctXz8jgXeky RWGEMb48ygzkp1K1AFOKDGrx5pUw3/+kJRFXq95vAUyG+57Ix5 nMVQLWbjSCySontFfp3iLJYOU0oGX2nHE8lRI6XsRrDTspcLOT GfW8oGotIBjG2OHUf1g1lgYn6Wl6ChI7y2W3Wtx1eRY24vadlZ 33APw
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/C2XOrgnYk11cUPxX7_jyzZqj2Po
Cc: "Joseph Salowey \(jsalowey\)" , "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 12:51:58 -0000

--001a1133358ac6b62a0505da2dc9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Manuel P=C3=A9gouri=C3=A9-Gonnard :

> On 26/09/2014 06:00, Joseph Salowey (jsalowey) wrote:
>


> > This is an announcement for the working group last call for
> > draft-ietf-tls-downgrade-scsv-00.  Please review the document and send
> your
> > comments to the list by Friday, October 17, 2014.
>


> Just to mention that I just implemented this. As expected (since it's one
> of the
> design goals of the draft), it was very easy.
>
> The only problem I ran into was an interop issue with OpenSSL, which
> apparently
> does not like it if the SCSV appears before the actual ciphersuites in th=
e
> ciphersuite list. If the intention of the draft was that the SCSV MUST be
> placed
> after the actual ciphersuites, it would be good to state so using normati=
ve
> language, rather than the current one which doesn't look normative:


This is not meant to be normative -- it's a bug in OpenSSL's server-side
code. [If ClientHello.cipher_suites includes TLS_FALLBACK_SCSV, all
following cipher suites are ignored by the server. This will be fixed in
the next release.]

Bodo

--001a1133358ac6b62a0505da2dc9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Manu=
el P=C3=A9gouri=C3=A9-Gonnard <mpg@polarssl.org>:
On 26/09/2014 06:00, Joseph Salowey (jsalowey)=
 wrote:
=C2=A0

> This is an announcement for the working group last call for

> draft-ietf-tls-downgrade-scsv-00.=C2=A0 Please review the document and=
 send your

> comments to the list by Friday, October 17, 2014.
=C2=A0

Just to mention that I just implemented this. As expected (since it&=
#39;s one of the

design goals of the draft), it was very easy.



The only problem I ran into was an interop issue with OpenSSL, which appare=
ntly

does not like it if the SCSV appears before the actual ciphersuites in the<=
br>
ciphersuite list. If the intention of the draft was that the SCSV MUST be p=
laced

after the actual ciphersuites, it would be good to state so using normative=


language, rather than the current one which doesn't look normative:

This is not meant to be normative -- it's =
a bug in OpenSSL's server-side code. [If ClientHello.cipher_suites incl=
udes TLS_FALLBACK_SCSV, all following cipher suites are ignored by the serv=
er. This will be fixed in the next release.]

Bodo<=
/div>



--001a1133358ac6b62a0505da2dc9--


From nobody Mon Oct 20 06:51:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7461A8733 for ; Mon, 20 Oct 2014 06:51:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiRN6D5ls7aI for ; Mon, 20 Oct 2014 06:51:08 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8FBF1A873A for ; Mon, 20 Oct 2014 06:50:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=KvILYkY2G+lryyLq6EQwhl51dSrqdQ1Kg8FsSQPwKiA=;  b=gmD05REZxIX/PZVCnJeXJUZEu6jeO1ftrbd36z4NhkYxBTHieg/Ilg6fzlZh1dyv5oE1U7S1Co2Qqw177FzuTUooukqUWjJNCPXl8rQQrKWHvC5S1ZPUp/pVHYimE1w9ljHf1nAEIqcn6omWX9vY1kUGARhN9bTQFPCy/Kwt0Uk=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgDMH-0003bX-T6; Mon, 20 Oct 2014 15:50:50 +0200
Message-ID: <5445133B.9020408@polarssl.org>
Date: Mon, 20 Oct 2014 15:50:51 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Bodo Moeller 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <54450068.5020101@polarssl.org> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LdONgd7UBazwPoE4y0vX6iHoue4
Cc: "Joseph Salowey \(jsalowey\)" , "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 13:51:09 -0000

On 20/10/2014 14:51, Bodo Moeller wrote:
> Manuel Pégourié-Gonnard :
> 
>> The only problem I ran into was an interop issue with OpenSSL, which 
>> apparently does not like it if the SCSV appears before the actual
>> ciphersuites in the ciphersuite list. If the intention of the draft was
>> that the SCSV MUST be placed after the actual ciphersuites, it would be
>> good to state so using normative language, rather than the current one
>> which doesn't look normative:
> 
> This is not meant to be normative -- it's a bug in OpenSSL's server-side
> code. [If ClientHello.cipher_suites includes TLS_FALLBACK_SCSV, all
> following cipher suites are ignored by the server. This will be fixed in
> the next release.]
> 
Ok, thanks.

Manuel.


From nobody Mon Oct 20 07:50:36 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA03B1A8A82 for ; Mon, 20 Oct 2014 07:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrEwvpzjcMre for ; Mon, 20 Oct 2014 07:50:31 -0700 (PDT)
Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A110B1A8AA3 for ; Mon, 20 Oct 2014 07:25:13 -0700 (PDT)
Received: by mail-yh0-f48.google.com with SMTP id v1so3219914yhn.35 for ; Mon, 20 Oct 2014 07:25:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qD+v+qKDCVbhWVdESoGFOe2GF55ltE4Sml9cV7rySAw=; b=HPMvLDl5oHVQnNJrfQ1mpOfQ3Tjg0GxCLezFEVCVQO1v1JG9sC9+JTZjm8/xXQ9PXR O1HMIQ3TNb3K2tMIHQD8utjfLhU7uHicdKLB+rN83E+PioJsiI8XNqJeE+4R2pYuJnOC o0GoOKyjZQp46Xtng5N4lVZI0m5FOUgLtKIYxHh6eFr6QMMssbA7bjr5scPLS/woJ4Wt 7qESuBjohgK7SuC+S0CIEpYwjVBnn/sy/XMhfWlkFRTDfgfuTLfcyALi0XcSuieSfN+k +d7nGwNSvliBJkpwLlokHrMvGJNn0Y5nzsti51Jl7fJGp39I6hTiLiyfXiDxSdui6dkb GGWQ==
MIME-Version: 1.0
X-Received: by 10.236.17.197 with SMTP id j45mr38686244yhj.49.1413815112970; Mon, 20 Oct 2014 07:25:12 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Mon, 20 Oct 2014 07:25:12 -0700 (PDT)
In-Reply-To: <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net>
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net>
Date: Mon, 20 Oct 2014 07:25:12 -0700
Message-ID: 
From: Watson Ladd 
To: Dan Harkins 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EWDT-uudfxZUCmYu_fy0g-qN7Ms
Cc: =?UTF-8?B?TWFudWVsIFDDg8KpZ291cmnDg8KpLUdvbm5hcmQ=?= , "tls@ietf.org" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 14:50:33 -0000

On Mon, Oct 20, 2014 at 5:13 AM, Dan Harkins  wrote:
>
> On Sun, October 19, 2014 7:35 am, Yoav Nir wrote:
>>
>> I also understand that in practice, PSK ciphersuites are used only by
>> small devices, whereas the web and SMTP and other things never went for
>> it. But the standards don=C3=A2=E2=82=AC=E2=84=A2t say that. They don=C3=
=A2=E2=82=AC=E2=84=A2t say that PSK
>> ciphersuites are especially for constrained devices. So if we insist tha=
t
>> the same TLS 1.3 be used for both, and we don=C3=A2=E2=82=AC=E2=84=A2t w=
ant to say that PSK is
>> for weak security, then we should have a good story of why PFS is not
>> needed for PSK uses, whereas it=C3=A2=E2=82=AC=E2=84=A2s essential for a=
ll RSA uses.  If I
>> understand the mechanism correctly, PSKs tend to be long-lived, and a
>> subsequent compromise of a PSK (even if it is expired at the time of
>> compromise) allows an attacker to decrypt the content of a TLS session.
>
>   The non-PFS PSK ciphersuites are no different than the widely
> discredited, and easily cracked, WPA-PSK mode of WiFi security. It would
> be a really bad idea to continue with these ciphersuites in TLS 1.3. But =
the
> issue is not just PFS (or the lack of it), it's that PSK ciphersuites are
> susceptible to dictionary attack.

Good luck with that: it says preshared key, not preshared password.
Yes, section 7 of RFC 4279 probably should be fleshed out more to deal
with this. Yes, we should have modern PAKE suites. SPAKE2, not
Dragonfly.

>
>> So either we believe that PSK compromise is unlikely, or we believe that
>> the data in a connection with a PSK ciphersuite is not future-sensitive.
>> If we don=C3=A2=E2=82=AC=E2=84=A2t, we=C3=A2=E2=82=AC=E2=84=A2re saying =
that we=C3=A2=E2=82=AC=E2=84=A2re just piling on security
>> nice-to-haves because we think the users can handle them.
>
>   There's no way that the protocol can be defined to justify that belief.
> What you're talking about is how people end up using the protocol and
> that is entirely out of the power of this WG. What we can do is to make
> TLS be as _misuse resistant_ as possible. And to do that we should not
> allow PSKs in TLS 1.3 unless they are used in a PAKE.
>
>   By the way, I'm surprised that no one is expressing outrageous outrage
> at the lack of a security proof for PSK ciphersuites.

What do you mean, lack of a security proof? RFC 4279 might not cite
one, but it's pretty obvious given the recent work on proving TLS
secure what it is you need to do to get one. I can get confidentiality
and authentication in the symbolic model immediately for RFC 4279, and
more realistic models aren't that much harder. Of course, if this
analysis wasn't done beforehand, it should have been.

To be clear, I have many, many complaints about the historic and
continuing performance of this WG. So long as non-cryptographers
attempt to do crypto, the results are just bad. Given that we can't
fix or bury our mistakes despite years of effort, we need to be
especially careful. However, so far it seems like TLS 1.3 will be in a
much better position than earlier attempts.

Sincerely,
Watson Ladd
>
>   regards,
>
>   Dan.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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


From nobody Mon Oct 20 10:16:08 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09961A1A98 for ; Mon, 20 Oct 2014 10:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNtG_LoiDti1 for ; Mon, 20 Oct 2014 10:16:04 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6652B1A1B21 for ; Mon, 20 Oct 2014 10:06:29 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CDA2E10224008; Mon, 20 Oct 2014 10:06:28 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 20 Oct 2014 10:06:29 -0700 (PDT)
Message-ID: <74986741b83a76277b2fcfd1e74a75d4.squirrel@www.trepanning.net>
In-Reply-To: 
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> 
Date: Mon, 20 Oct 2014 10:06:29 -0700 (PDT)
From: "Dan Harkins" 
To: "Watson Ladd" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k21jI83kZ207r00bZ7AyTIdL8mQ
Cc: "tls@ietf.org" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 17:16:06 -0000

On Mon, October 20, 2014 7:25 am, Watson Ladd wrote:
> On Mon, Oct 20, 2014 at 5:13 AM, Dan Harkins  wrote:
>>
>> On Sun, October 19, 2014 7:35 am, Yoav Nir wrote:
>>>
>>> I also understand that in practice, PSK ciphersuites are used only by
>>> small devices, whereas the web and SMTP and other things never went for
>>> it. But the standards don’t say that. They don’t say that
>>> PSK
>>> ciphersuites are especially for constrained devices. So if we insist
>>> that
>>> the same TLS 1.3 be used for both, and we don’t want to say that
>>> PSK is
>>> for weak security, then we should have a good story of why PFS is not
>>> needed for PSK uses, whereas it’s essential for all RSA uses.
>>> If I
>>> understand the mechanism correctly, PSKs tend to be long-lived, and a
>>> subsequent compromise of a PSK (even if it is expired at the time of
>>> compromise) allows an attacker to decrypt the content of a TLS session.
>>
>>   The non-PFS PSK ciphersuites are no different than the widely
>> discredited, and easily cracked, WPA-PSK mode of WiFi security. It would
>> be a really bad idea to continue with these ciphersuites in TLS 1.3. But
>> the
>> issue is not just PFS (or the lack of it), it's that PSK ciphersuites
>> are
>> susceptible to dictionary attack.
>
> Good luck with that: it says preshared key, not preshared password.
> Yes, section 7 of RFC 4279 probably should be fleshed out more to deal
> with this. Yes, we should have modern PAKE suites. SPAKE2, not
> Dragonfly.

  There is nothing to flesh out because you seem to not understand
what a dictionary attack is-- but you're in company because neither
did the editors of that RFC.

  Protocols that use a static, symmetric credential like a PSK (or a
password, the difference is semantic) are all flawed because the
adversary is always assumed to have access to a pool from which
the PSK (or password is drawn. Resistance against dictionary attack
is then a demonstration that the advantage gained by the adversary
is due to _interaction_ and not _computation_.

  Merely making the pool from which the PSK is drawn, for instance
by making it a bigger or including mixed case, etc, does not make
the protocol resistant to dictionary attack. With the TLS PSK
ciphersuites the adversarial advantage always grows with
computation no matter how big, or complex, you make the PSK.

  Therefore, all of the TLS PSK ciphersuites are susceptible to
dictionary attack, notwithstanding any addition section 7 flesh
you wish to add.

>>> So either we believe that PSK compromise is unlikely, or we believe
>>> that
>>> the data in a connection with a PSK ciphersuite is not
>>> future-sensitive.
>>> If we don’t, we’re saying that we’re just piling
>>> on security
>>> nice-to-haves because we think the users can handle them.
>>
>>   There's no way that the protocol can be defined to justify that
>> belief.
>> What you're talking about is how people end up using the protocol and
>> that is entirely out of the power of this WG. What we can do is to make
>> TLS be as _misuse resistant_ as possible. And to do that we should not
>> allow PSKs in TLS 1.3 unless they are used in a PAKE.
>>
>>   By the way, I'm surprised that no one is expressing outrageous outrage
>> at the lack of a security proof for PSK ciphersuites.
>
> What do you mean, lack of a security proof? RFC 4279 might not cite
> one, but it's pretty obvious given the recent work on proving TLS
> secure what it is you need to do to get one. I can get confidentiality
> and authentication in the symbolic model immediately for RFC 4279, and
> more realistic models aren't that much harder. Of course, if this
> analysis wasn't done beforehand, it should have been.

  If such a proof would be enough to satisfy you over the security
of the TLS PSK ciphersuites then it would be enough to satisfy you
over the TLS-pwd ciphersuites.

  Dan.



From nobody Mon Oct 20 10:20:49 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0401A8032 for ; Mon, 20 Oct 2014 10:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krQ4Tkq6LOua for ; Mon, 20 Oct 2014 10:20:43 -0700 (PDT)
Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BE71A87E1 for ; Mon, 20 Oct 2014 10:18:14 -0700 (PDT)
Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s9KHICsu004444; Mon, 20 Oct 2014 13:18:12 -0400
Date: Mon, 20 Oct 2014 13:18:11 -0400 (EDT)
From: Nikos Mavrogiannopoulos 
To: Bodo Moeller 
Message-ID: <460682079.47331533.1413825491684.JavaMail.zimbra@redhat.com>
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>  <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com>  <1413807699.2597.14.camel@dhcp-2-127.brq.redhat.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.5.82.7]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF29 (Linux)/8.0.6_GA_5922)
Thread-Topic: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: f2ZW4uHMH2hDn/pTLT0JyZPaAP/CkQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Tq_CobcXdWmXJMWuAhz2lsDOR6U
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 17:20:45 -0000

> > It certainly makes sense to fix those broken servers. I disagree with
> > > fixing them *instead* of deploying TLS_FALLBACK_SCSV; I think that's a
> > > false dichotomy. If you are willing to stop fallback retries in the
> > > client products that Red Hat distributes right now, great (do you?),
> > > but clearly not everyone is willing to take that step at this time.
> > > Until it has happened, clients already can benefit from
> > > TLS_FALLBACK_SCSV.
> > I disagree. It is a correct dichotomy :) If the servers are fixed, there
> > is no use for the fallback SCSV, as clients would not need to perform
> > the insecure fallback.
> True, but clearly they aren't fixed *now*, and more importantly, various
> current clients *do* still find it necessary to use fallback retries to
> work with such servers.
> I agree that TLS_FALLBACK_SCSV is hypothetically pointless :-)

No, not only pointless, it gives the broken servers an incentive to continue
being broken. With this change, clients still consider the servers that
require a downgrade dance secure. Why should that be the case? Why for example
chrome or firefox doesn't warn on these servers? They are certainly not
secure.

If the draft should mention that a compliant to SCSV interactive client MUST
warn the user in case of a fallback dance, then yes, I would agree that the
draft is a step forward. I believe the goal must be the elimination of 
non-compliant servers, not only to patch things up until the next attack.

> As of the argument that clients would be protected from the SCSV, that
> > only works if both the clients _and_ the servers are updated to support
> > the fallback SCSV. Why is that step necessary, if we can instead fix the
> > clients and the servers to properly negotiate TLS?
> Using the SCSV already helps if *some* servers have been updated to support
> it: connections to these servers, at least, will be more secure. For other
> servers, you get what you have now.

I agree on that, but the issue there is that we tolerate non-TLS compliant
servers and we consider them equally secure, even though your attack shows
that they are not.

regards,
Nikos


From nobody Mon Oct 20 10:30:41 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111A31A872C for ; Mon, 20 Oct 2014 10:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rearLmlyQE7K for ; Mon, 20 Oct 2014 10:30:37 -0700 (PDT)
Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740221A02BE for ; Mon, 20 Oct 2014 10:30:37 -0700 (PDT)
Received: by mail-ob0-f170.google.com with SMTP id uz6so4301934obc.1 for ; Mon, 20 Oct 2014 10:30:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DN7dx9lXk0EGNNoYlhhlWXC0YlJUp0RI0TSrbM2RYZU=; b=eqgYcQIkM1d+5klzmdD9wAHaOVZU9S62RT7iH9n2EXRhGs/++sceum0NYQl9QhlcnJ DfBmGg7R10aCQBrlMUb0L4dSMkG/1T+SzNaz4wVfWEdQo56ulyrk8q0+2T8igNMUP0yC yuMlMK3nm3pJI+vJg4V4tWg8ls5YnJ9qFN/kyudR9JGD7HCcM/ViFjqwzt0GG3b5y5sf ULffdnmfQvlfIfMpXbwMhlNvcJxFr5g913MUGEL6Zl/dYihyN118QHGCr6viF+JtmBUU s/Zbs1fLB5oGn5WIKrMiKHPZBSyXyU98tWZDYbLRRO/pwOFg61JTAUyKcgd2Nbtl/PtP IXEg==
X-Gm-Message-State: ALoCoQmm/dN9aERjjbmi3aSj3W4SMLKJ+mP2Fj0UZL6mBAqo6XyjMgOsa4hsMIX+0DExLKIimpV9
MIME-Version: 1.0
X-Received: by 10.60.57.41 with SMTP id f9mr24289959oeq.17.1413826236848; Mon, 20 Oct 2014 10:30:36 -0700 (PDT)
Received: by 10.76.93.9 with HTTP; Mon, 20 Oct 2014 10:30:36 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>  <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com> 
Date: Mon, 20 Oct 2014 10:30:36 -0700
Message-ID: 
From: Brian Smith 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=089e015389ee9f36630505de1264
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1sf214N6v9z1lHWOYtl_NeVesCY
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 17:30:39 -0000

--089e015389ee9f36630505de1264
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 20, 2014 at 4:53 AM, Martin Thomson 
wrote:

> On 20 October 2014 04:47, Nikos Mavrogiannopoulos  wrote:
> > Indeed, there is an arguments to keep that mechanism, as there are still
> > some TLS 1.3 intolerant servers. But instead of prolonging the life of
> > such an insecure mechanism wouldn't it make sense to fix those broken
> > servers instead; e.g., by peer pressure by documenting the
> > implementations that are not TLS 1.3-ready in [0]?
>
> I think that we should do that, but as a practical matter, I suspect
> that we'll be stuck with some amount of fallback for a while yet.  I
> find the TLS 1.3 intolerance numbers pretty alarming in this regard;
> even with rapid improvement, I doubt it will go away quickly.


That's why the version negotiation mechanism for TLS 1.3 should be
different. We've already made the mistake 3 times of trying to use
ClientHello.client_version to negotiate versions and 3 times we've learned
that it has terrible compatibility issues. Why keep repeating that same
mistake? By negotiating TLS 1.3 with a new extension, and keeping
ClientHello.client_version = TLS 1.2 for TLS 1.3, you avoid the
compatibility costs without losing anything.

Also, even if we decide to keep making that mistake, browsers could stop
fallback for TLS 1.3 -> TLS 1.2, while dropping the rest.

Cheers,
Brian

--089e015389ee9f36630505de1264
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Oct 20, 2014 at 4:53 AM, Martin Thomson <martin.thomson@gmail=
.com> wrote:
On 20 October 2014 04:47, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:

> Indeed, there is an arguments to keep that mechanism, as there are sti=
ll

> some TLS 1.3 intolerant servers. But instead of prolonging the life of=


> such an insecure mechanism wouldn't it make sense to fix those bro=
ken

> servers instead; e.g., by peer pressure by documenting the

> implementations that are not TLS 1.3-ready in [0]?



I think that we should do that, but as a practical matter, I suspect=


that we'll be stuck with some amount of fallback for a while yet.=C2=A0=
 I

find the TLS 1.3 intolerance numbers pretty alarming in this regard;

even with rapid improvement, I doubt it will go away quickly.
<=
div>
That's why the version negotiation mechanism for TLS=
 1.3 should be different. We've already made the mistake 3 times of try=
ing to use ClientHello.client_version to negotiate versions and 3 times we&=
#39;ve learned that it has terrible compatibility issues. Why keep repeatin=
g that same mistake? By negotiating TLS 1.3 with a new extension, and keepi=
ng ClientHello.client_version =3D TLS 1.2 for TLS 1.3, you avoid the compat=
ibility costs without losing anything.

Also, even =
if we decide to keep making that mistake, browsers could stop fallback for =
TLS 1.3 -> TLS 1.2, while dropping the rest.

Ch=
eers,
Brian


--089e015389ee9f36630505de1264--


From nobody Mon Oct 20 10:32:53 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17D81A872C for ; Mon, 20 Oct 2014 10:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuR25TGNFBHa for ; Mon, 20 Oct 2014 10:32:50 -0700 (PDT)
Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2730B1A02BE for ; Mon, 20 Oct 2014 10:32:49 -0700 (PDT)
Received: by mail-yh0-f44.google.com with SMTP id i57so3577892yha.17 for ; Mon, 20 Oct 2014 10:32:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q295UaZ6XMo5ie0Nh7OH1+RQQwfZ1k75D85Bqri1+/w=; b=Ek5PEEjyAPK3faBwxSUzYZhmwIsa8074R73/U0/9CrcicGVIYzi334oYbjupJ+MNiQ 4f2mTs67vlf39foY+j07XMqN0yrH/vi8IJggw4q86tJ1PhO01F1ep0Jzj90mb4Blrokj qy61qc+mQRbKiBkT7MmkUv23RUgk1ZSoqzg5LFDlBQQSClPnt8e0kGunpLnp8FEzr9l4 5Gu3ddq4sn8kSY/CilD0r0qv6YmaLcjnRseHNYO1C56mGupZU1B5ndZyg5faHuPAcayX N/NBKNxsyF+TgyP2aMG4bu+lRRdYBcGhEO/4w1VIxZ2+b/mMoJvbJY0MsdBXyrQHdY6S O/gQ==
MIME-Version: 1.0
X-Received: by 10.236.30.197 with SMTP id k45mr4737242yha.163.1413826369288; Mon, 20 Oct 2014 10:32:49 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Mon, 20 Oct 2014 10:32:49 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Mon, 20 Oct 2014 10:32:49 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com>   <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>  <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com>  
Date: Mon, 20 Oct 2014 10:32:49 -0700
Message-ID: 
From: Watson Ladd 
To: Brian Smith 
Content-Type: multipart/alternative; boundary=089e01634d348400730505de1aaf
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/t-X2s-eVM_d8XipCqp-CROJQllI
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 17:32:53 -0000

--089e01634d348400730505de1aaf
Content-Type: text/plain; charset=UTF-8

On Oct 20, 2014 10:30 AM, "Brian Smith"  wrote:
>
> On Mon, Oct 20, 2014 at 4:53 AM, Martin Thomson 
wrote:
>>
>> On 20 October 2014 04:47, Nikos Mavrogiannopoulos 
wrote:
>> > Indeed, there is an arguments to keep that mechanism, as there are
still
>> > some TLS 1.3 intolerant servers. But instead of prolonging the life of
>> > such an insecure mechanism wouldn't it make sense to fix those broken
>> > servers instead; e.g., by peer pressure by documenting the
>> > implementations that are not TLS 1.3-ready in [0]?
>>
>> I think that we should do that, but as a practical matter, I suspect
>> that we'll be stuck with some amount of fallback for a while yet.  I
>> find the TLS 1.3 intolerance numbers pretty alarming in this regard;
>> even with rapid improvement, I doubt it will go away quickly.
>
>
> That's why the version negotiation mechanism for TLS 1.3 should be
different. We've already made the mistake 3 times of trying to use
ClientHello.client_version to negotiate versions and 3 times we've learned
that it has terrible compatibility issues. Why keep repeating that same
mistake? By negotiating TLS 1.3 with a new extension, and keeping
ClientHello.client_version = TLS 1.2 for TLS 1.3, you avoid the
compatibility costs without losing anything.
>
> Also, even if we decide to keep making that mistake, browsers could stop
fallback for TLS 1.3 -> TLS 1.2, while dropping the rest.

After all these years you would think software vendors would test proper
version negotiation before release.

>
> Cheers,
> Brian
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--089e01634d348400730505de1aaf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Oct 20, 2014 10:30 AM, "Brian Smith" <brian@briansmith.org> wrote:

>

> On Mon, Oct 20, 2014 at 4:53 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

>>

>> On 20 October 2014 04:47, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:

>> > Indeed, there is an arguments to keep that mechanism, as ther=
e are still

>> > some TLS 1.3 intolerant servers. But instead of prolonging th=
e life of

>> > such an insecure mechanism wouldn't it make sense to fix =
those broken

>> > servers instead; e.g., by peer pressure by documenting the
>> > implementations that are not TLS 1.3-ready in [0]?

>>

>> I think that we should do that, but as a practical matter, I suspe=
ct

>> that we'll be stuck with some amount of fallback for a while y=
et.=C2=A0 I

>> find the TLS 1.3 intolerance numbers pretty alarming in this regar=
d;

>> even with rapid improvement, I doubt it will go away quickly.

>

>

> That's why the version negotiation mechanism for TLS 1.3 should be=
 different. We've already made the mistake 3 times of trying to use Cli=
entHello.client_version to negotiate versions and 3 times we've learned=
 that it has terrible compatibility issues. Why keep repeating that same mi=
stake? By negotiating TLS 1.3 with a new extension, and keeping ClientHello=
.client_version =3D TLS 1.2 for TLS 1.3, you avoid the compatibility costs =
without losing anything.

>

> Also, even if we decide to keep making that mistake, browsers could st=
op fallback for TLS 1.3 -> TLS 1.2, while dropping the rest.


After all these years you would think software vendors would=
 test proper version negotiation before release.


>

> Cheers,

> Brian

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf=
.org/mailman/listinfo/tls

>




--089e01634d348400730505de1aaf--


From nobody Mon Oct 20 10:33:04 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B791A87A1 for ; Mon, 20 Oct 2014 10:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qr4BkXe0lSw for ; Mon, 20 Oct 2014 10:32:56 -0700 (PDT)
Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8151A02BE for ; Mon, 20 Oct 2014 10:32:56 -0700 (PDT)
Received: by mail-ob0-f180.google.com with SMTP id va2so4209010obc.39 for ; Mon, 20 Oct 2014 10:32:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gJDIOKghzemomLmcmOM5/7nhENVuqUEO67jpJpaLS7o=; b=hrGtP/qPs3XjkoYQm847Bn5L1YdTmRSvz1ZB0QQsC7xWSpaCpRP7a5rvue7bbE+78O DieAfK0aQ/9DWdATZVpuLmJYlEVwp2AHtJY7RgBirwyjfLS39GmyTLRyMZOKZ8fkKepu GPsmTfPqmnO6ll7BaMu5Sy8kQzuk3iClg6MGUk8w4QqRvfFHlrkoivsyoValjxDoASIm fTdtaJKcC4B68Ge7V9uKjrbVuCQGeYdX3fJGKL7EGz5WvZr6ybQDNRXVGNUsF/A2UK7H syHhGcqHbjp9Ru+kwKfi1foc7p8tjgtm9DGSKzhzlkCuOZVlF8KTcSQkBjx4Z8MSFVYF RZsg==
X-Gm-Message-State: ALoCoQmFuUGI2Z0MtNjNCvpTYcOMiyr0bQSIMk1VfE5bsBgq/Yhozp4lDygCHH70IgxUgt/moNAw
MIME-Version: 1.0
X-Received: by 10.202.81.68 with SMTP id f65mr2966439oib.73.1413826375803; Mon, 20 Oct 2014 10:32:55 -0700 (PDT)
Received: by 10.76.93.9 with HTTP; Mon, 20 Oct 2014 10:32:55 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <54450068.5020101@polarssl.org> 
Date: Mon, 20 Oct 2014 10:32:55 -0700
Message-ID: 
From: Brian Smith 
To: Bodo Moeller 
Content-Type: multipart/alternative; boundary=001a113d7818e78de10505de1a1c
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PIJkC0yFCzP6fmnBMmBLGMNzomU
Cc: "Joseph Salowey \(jsalowey\)" , =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 17:33:01 -0000

--001a113d7818e78de10505de1a1c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 20, 2014 at 5:51 AM, Bodo Moeller  wrote:

> Manuel P=C3=A9gouri=C3=A9-Gonnard :
>
>> On 26/09/2014 06:00, Joseph Salowey (jsalowey) wrote:
>>
>
>
>> > This is an announcement for the working group last call for
>> > draft-ietf-tls-downgrade-scsv-00.  Please review the document and send
>> your
>> > comments to the list by Friday, October 17, 2014.
>>
>
>
>> Just to mention that I just implemented this. As expected (since it's on=
e
>> of the
>> design goals of the draft), it was very easy.
>>
>> The only problem I ran into was an interop issue with OpenSSL, which
>> apparently
>> does not like it if the SCSV appears before the actual ciphersuites in t=
he
>> ciphersuite list. If the intention of the draft was that the SCSV MUST b=
e
>> placed
>> after the actual ciphersuites, it would be good to state so using
>> normative
>> language, rather than the current one which doesn't look normative:
>
>
> This is not meant to be normative -- it's a bug in OpenSSL's server-side
> code. [If ClientHello.cipher_suites includes TLS_FALLBACK_SCSV, all
> following cipher suites are ignored by the server. This will be fixed in
> the next release.]
>

For compatibility reasons, clients should put the renegotiation info and
TLS_FALLBACK_SCSV at the end of the cipher suite list, to avoid this bug
and similar bugs in other server software. This should be added to the
draft too.

Cheers,
Brian

--001a113d7818e78de10505de1a1c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Oct 20, 2014 at 5:51 AM, Bodo Moeller <bmoeller@acm.org> =
wrote:
Manuel P=C3=A9gouri=C3=A9-Gonnard <mpg=
@polarssl.org>:
On 26/09/2014 06:00, Joseph Salowey (jsalowey) wrote:
=C2=A0

> This is an announcement for the working group last call for

> draft-ietf-tls-downgrade-scsv-00.=C2=A0 Please review the document and=
 send your

> comments to the list by Friday, October 17, 2014.
=C2=A0

Just to mention that I just implemented this. As expected (since it&=
#39;s one of the

design goals of the draft), it was very easy.



The only problem I ran into was an interop issue with OpenSSL, which appare=
ntly

does not like it if the SCSV appears before the actual ciphersuites in the<=
br>
ciphersuite list. If the intention of the draft was that the SCSV MUST be p=
laced

after the actual ciphersuites, it would be good to state so using normative=


language, rather than the current one which doesn't look normative:

This is not meant to be normative -- it=
's a bug in OpenSSL's server-side code. [If ClientHello.cipher_suit=
es includes TLS_FALLBACK_SCSV, all following cipher suites are ignored by t=
he server. This will be fixed in the next release.]
=


For compatibility reasons, clients should =
put the renegotiation info and TLS_FALLBACK_SCSV at the end of the cipher s=
uite list, to avoid this bug and similar bugs in other server software. Thi=
s should be added to the draft too.

Cheers,
<=
div>Brian


--001a113d7818e78de10505de1a1c--


From nobody Mon Oct 20 11:07:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E504B1A87A9 for ; Mon, 20 Oct 2014 11:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N__bFxtVlADI for ; Mon, 20 Oct 2014 11:07:04 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046BE1A8A86 for ; Mon, 20 Oct 2014 11:06:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=0aZuJZUwZLFESJcs8RnCcoLBgZyEioDMZXWeSEJ0xF0=;  b=lB2sRs4qDE0jE9nLF+hj3TtsVW9yIGYuxJ815OuC1vuj7vty8UmTo+Y/6wEMt7no4a+aKxtLCQwTZTeNRxQuOk8KabjdPCCiBHUrPtne90AvCmuA+dbduiXZPk+yfi8gVp+OmQopwUMk9zmPMtejhU7vor13MIlo26nzwx9Z3rs=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgHM0-0003xF-MK; Mon, 20 Oct 2014 20:06:49 +0200
Message-ID: <54454F3C.7010305@polarssl.org>
Date: Mon, 20 Oct 2014 20:06:52 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Dan Harkins ,  Watson Ladd 
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net>  <74986741b83a76277b2fcfd1e74a75d4.squirrel@www.trepanning.net>
In-Reply-To: <74986741b83a76277b2fcfd1e74a75d4.squirrel@www.trepanning.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TKInHIFbyKkAdTifT6e_JsCDrC8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 18:07:08 -0000

On 20/10/2014 19:06, Dan Harkins wrote:
>   There is nothing to flesh out because you seem to not understand
> what a dictionary attack is-- but you're in company because neither
> did the editors of that RFC.
> 
>   Protocols that use a static, symmetric credential like a PSK (or a
> password, the difference is semantic) are all flawed because the
> adversary is always assumed to have access to a pool from which
> the PSK (or password is drawn. Resistance against dictionary attack
> is then a demonstration that the advantage gained by the adversary
> is due to _interaction_ and not _computation_.
> 
>   Merely making the pool from which the PSK is drawn, for instance
> by making it a bigger or including mixed case, etc, does not make
> the protocol resistant to dictionary attack.

>From a theoretical standpoint, the PSK key exchange is indeed vulnerable to a
dictionary attack with this definition. In practice, if your keys are 128-bit
long and chosen uniformly at random using a good source of entropy, I doubt any
real-world adversary is able to gain a non-negligible advantage in the
foreseeable future.

Also, it should be noted that with this definition, the TLS session keys are
vulnerable to a dictionary attack too. In practice, it's not a problem either
for the same reason. Obviously the difference between the pre-shared key and the
TLS session keys is that the later is short-term while the former is long-term.
Which basically boils down to the point that PSK lacks FS.

Are you sure you have point besides:
- pre-shared key must be chosen with sufficient entropy and
- PSK does not offer FS?

Manuel.

PS: by the way, it seems to me RSA key exchange as it exists in TLS 1.2 is also
vulnerable to dictionary attack with the above definition. (Obviously there are
more efficient attacks here.)


From nobody Mon Oct 20 11:15:51 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560381A8ABC for ; Mon, 20 Oct 2014 11:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VAFPMcK7AAe for ; Mon, 20 Oct 2014 11:15:46 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F4C1A8AD6 for ; Mon, 20 Oct 2014 11:15:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=keK5UiD/QZ3uS7ijSnn4MS+5+7VQR8kwnxnPK5n4r3w=;  b=axH09zxVRe1VdLmH7KLnKL9o8AvOGvEaFta2m3Vo0AWygM7YMClXzOCkUj34GZz3TzbuFChhnQNX/vH2tcTyDtvIdNd5uNODvBZdmkFWwn8kD9IU0mNCAmU59InThPWZWy1is5Hhh8CkL801Y3elfJwz2o4N1irmW9iLt+tTTC8=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgHUE-0003y8-Uc; Mon, 20 Oct 2014 20:15:19 +0200
Message-ID: <5445513A.50703@polarssl.org>
Date: Mon, 20 Oct 2014 20:15:22 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Dan Harkins ,  Watson Ladd 
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net>  <74986741b83a76277b2fcfd1e74a75d4.squirrel@www.trepanning.net>
In-Reply-To: <74986741b83a76277b2fcfd1e74a75d4.squirrel@www.trepanning.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4c2e0K31FHeYMs6HV-l1TGz2enk
Cc: "tls@ietf.org" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 18:15:47 -0000

On 20/10/2014 19:06, Dan Harkins wrote:
>   Merely making the pool from which the PSK is drawn, for instance
> by making it a bigger or including mixed case

PS: the above reference to "mixed case" makes me think there is a serious
misunderstanding about how keys should be generated. They should be the output
of a properly seeded cryptographically secure DRBG. The very notion of "mixed
case" does not make any sense in this context.

If such misinterpretations can be made, then indeed the RFC should be revised to
be much more explicit about the meaning of pre-shared *key* (as opposed to
password).

Manuel.


From nobody Mon Oct 20 11:46:51 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F05B1A9045 for ; Mon, 20 Oct 2014 11:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level: 
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZwwVZ7v1JMS for ; Mon, 20 Oct 2014 11:46:47 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6071A9027 for ; Mon, 20 Oct 2014 11:46:24 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 21386284EB; Mon, 20 Oct 2014 18:46:24 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 0AF35284E6; Mon, 20 Oct 2014 18:46:24 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 833E12029; Mon, 20 Oct 2014 18:46:23 +0000 (GMT)
Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 20 Oct 2014 14:46:22 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Mon, 20 Oct 2014 14:46:22 -0400
From: "Salz, Rich" 
To: =?iso-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , "Joseph Salowey (jsalowey)" , "" 
Date: Mon, 20 Oct 2014 14:46:22 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/sYaqAkKsi6L++Tc6Zg75tOR10kwAMa3NA
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4830@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <54450068.5020101@polarssl.org>
In-Reply-To: <54450068.5020101@polarssl.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BLi449faQnvnLEDOcatXornoOkk
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 18:46:49 -0000

I don't think the cipher can appear anywhere.
Can you send details of the OpenSSL bug?
Thanks.


-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Mon Oct 20 11:52:47 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD371A903F for ; Mon, 20 Oct 2014 11:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84UQd3Jd_9G5 for ; Mon, 20 Oct 2014 11:52:45 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1E41A9025 for ; Mon, 20 Oct 2014 11:52:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=RHkviqHS+yZkhlfddc27C3HAa9z7mYrJIfncUDNn+Nw=;  b=G+EYNx/0UoQNwBszJYPY4lWEc1ZndIcAHAAsz3GdBUZoy3xHE2VSu+Hc4s2o6Ec3wU24cJcwTYSTSy3Pu2dGKed6xdjo1/WtyWfYEG7v+AdveOTzlYqgXu8hPAlWa8XGjv8/hRbStMI/y7zdF5ACLOEtq1jnRwsWv5X9rHLbHMo=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgI4K-00040f-Dw; Mon, 20 Oct 2014 20:52:36 +0200
Message-ID: <544559F7.4000306@polarssl.org>
Date: Mon, 20 Oct 2014 20:52:39 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Salz, Rich" ,  "Joseph Salowey (jsalowey)" , "" 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <54450068.5020101@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4830@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4830@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lWQ6aVa5xfzrl50dxdh8As87mrk
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 18:52:46 -0000

On 20/10/2014 20:46, Salz, Rich wrote:
> I don't think the cipher can appear anywhere.
> Can you send details of the OpenSSL bug?

It's #3575.

Manuel.


From nobody Mon Oct 20 11:57:03 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2401B1A904D for ; Mon, 20 Oct 2014 11:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.31
X-Spam-Level: 
X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOAAEmb9J9Ha for ; Mon, 20 Oct 2014 11:57:01 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 5C28E1A9040 for ; Mon, 20 Oct 2014 11:57:01 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 794294857A; Mon, 20 Oct 2014 18:57:00 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 6D96448579; Mon, 20 Oct 2014 18:57:00 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 558AE9803D; Mon, 20 Oct 2014 18:57:00 +0000 (GMT)
Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 20 Oct 2014 14:56:59 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Mon, 20 Oct 2014 14:56:59 -0400
From: "Salz, Rich" 
To: =?iso-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , "Joseph Salowey (jsalowey)" , "" 
Date: Mon, 20 Oct 2014 14:56:36 -0400
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: Ac/slw0b4MwuY087RpmBqSCn8muqaQAAHqcg
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4845@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <54450068.5020101@polarssl.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4830@USMBX1.msg.corp.akamai.com> <544559F7.4000306@polarssl.org>
In-Reply-To: <544559F7.4000306@polarssl.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qvF5y6uJO8mQxVFk934VtDChe8c
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 18:57:02 -0000

> It's #3575.

Ah thanks.  Yup, Bodo's fixing it :)

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Mon Oct 20 11:57:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BD21A90EE for ; Mon, 20 Oct 2014 11:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLd_q1QOELBm for ; Mon, 20 Oct 2014 11:57:03 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7751A90E7 for ; Mon, 20 Oct 2014 11:57:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=6fNuzungkUPM0jRHaMzZrVQFChDxmo9SVoDrqmnL1Dw=;  b=eWFjlF0V3AU3yCmDUgIURBvoe4sNlubFrNJQa434KKJcVT+O0fsT9IWua0dJDPCWInpxGqb9S6H9e5CGURbmgO3cAvdRu43jCLMbzHTn3N9YHofLO/sRXYaJbBIQDA9Uv51xfuSkTiuSn9AAvfHwPpjO1nGpWOZI4QDVBi4OExM=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgI8V-00041H-Bb; Mon, 20 Oct 2014 20:56:55 +0200
Message-ID: <54455AFB.1060401@polarssl.org>
Date: Mon, 20 Oct 2014 20:56:59 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Brian Smith , Bodo Moeller 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <54450068.5020101@polarssl.org>  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q-JzXTxbfb1hdK2hkV5hQbrE2ks
Cc: "Joseph Salowey \(jsalowey\)" , "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 18:57:04 -0000

On 20/10/2014 19:32, Brian Smith wrote:
> For compatibility reasons, clients should put the renegotiation info and
> TLS_FALLBACK_SCSV at the end of the cipher suite list, to avoid this bug
> and similar bugs in other server software. This should be added to the
> draft too.
> 
Currently, PolarSSL puts the renego SCSV at the beginning of the list and we
didn't get any report of interop issues so far. However, if there's consensus
that it's safer to put the SCSV at the end, I'll follow your advice and change that.

(For the fallback scsv, obviously I added it at the end since we want to interop
with the current version of OpenSSL.)

Manuel.


From nobody Mon Oct 20 12:08:51 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0081A9177 for ; Mon, 20 Oct 2014 12:08:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnB86sNFZvjv for ; Mon, 20 Oct 2014 12:08:44 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 288071A9100 for ; Mon, 20 Oct 2014 12:08:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=WVZjuxaqwocu4gJCNBESmb/Lu9SXvHGqWDClYfgbaHw=;  b=YkPz3advIVyAWMq9TGJs+gmIa4wQt8mk72iCFt/lkrwfmqv1Fod54vRqCpYHtpdRkCkoCBhy5UHyIV5+8bBSqNkINnAw0Pm0rzAiLe/EyOVYfe2OhDOTVAsfT1j4xrK+ym8o/Z5fKVRUZfR7TYP/0UeGxkfjkWrIkkBX6IXhvXw=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgIJg-00042R-3C; Mon, 20 Oct 2014 21:08:28 +0200
Message-ID: <54455DAF.7030706@polarssl.org>
Date: Mon, 20 Oct 2014 21:08:31 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Alfredo Pironti , "tls@ietf.org" 
References: <20141006131625.5451.13842.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-lv0IrzqF6npMnzOgSafKocbPuE
Subject: Re: [TLS] I-D Action: draft-ietf-tls-session-hash-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 19:08:45 -0000

Hi,

On 06/10/2014 15:27, Alfredo Pironti wrote:
> We've set up a test server, available at mitls.org:2443. The running
> implementation is miTLS, with experimental support for the extended master
> secret extension.
> 
Thanks! I just had a go at implementing it, and interop with your test server
works fine for TLS 1.2 down to 1.0 included, but fails for SSL 3.0 (server
rejects Finished with bad_record_mac, most likely we didn't compute the MS in
the same way).

It may very well be a stupid mistake on my side, since I'm getting a bit tired
now, but I thought I'd just check with you if the test server is implementing
the latest (02) version of the draft for SSLv3, just to be sure.

Thanks,
Manuel.

PS: I noted a typo in section 4.2: "SSL 3.0 does not defne a PRF function" defne
-> define. Also, arguably "function" is redundant after PRF.


From nobody Mon Oct 20 12:20:30 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8409F1AC3B2 for ; Mon, 20 Oct 2014 12:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.567
X-Spam-Level: 
X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRMrkModhF5e for ; Mon, 20 Oct 2014 12:20:23 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A6E0E1AC3C6 for ; Mon, 20 Oct 2014 12:20:23 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1742710224008; Mon, 20 Oct 2014 12:20:23 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 20 Oct 2014 12:20:23 -0700 (PDT)
Message-ID: 
In-Reply-To: <54454F3C.7010305@polarssl.org>
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net>  <74986741b83a76277b2fcfd1e74a75d4.squirrel@www.trepanning.net> <54454F3C.7010305@polarssl.org>
Date: Mon, 20 Oct 2014 12:20:23 -0700 (PDT)
From: "Dan Harkins" 
To: Manuel =?iso-8859-1?Q?P=E9gouri=E9-Gonnard?= 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w5p2tPY2On6VrB8GC23wNCeAa2o
Cc: "tls@ietf.org" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 19:20:26 -0000

On Mon, October 20, 2014 11:06 am, Manuel Pégourié-Gonnard wrote:
> On 20/10/2014 19:06, Dan Harkins wrote:
>>   There is nothing to flesh out because you seem to not understand
>> what a dictionary attack is-- but you're in company because neither
>> did the editors of that RFC.
>>
>>   Protocols that use a static, symmetric credential like a PSK (or a
>> password, the difference is semantic) are all flawed because the
>> adversary is always assumed to have access to a pool from which
>> the PSK (or password is drawn. Resistance against dictionary attack
>> is then a demonstration that the advantage gained by the adversary
>> is due to _interaction_ and not _computation_.
>>
>>   Merely making the pool from which the PSK is drawn, for instance
>> by making it a bigger or including mixed case, etc, does not make
>> the protocol resistant to dictionary attack.
>
> From a theoretical standpoint, the PSK key exchange is indeed vulnerable
> to a
> dictionary attack with this definition. In practice, if your keys are
> 128-bit
> long and chosen uniformly at random using a good source of entropy, I
> doubt any
> real-world adversary is able to gain a non-negligible advantage in the
> foreseeable future.

  The justification for these ciphersuites is some constrained device that
has a small data and code size. But if you can not only generate 128-bit
long uniformly random keys from a good source of entropy and also
securely provision them on 2 (or more) devices then you don't need TLS.
Just do static keyed symmetric crypto and you save even more data
and code by eliminating TLS!

  In practice, these things are deployed by people who probably do not
read the RFC in question, are in a hurry, and don't understand the
security implications of their use of TLS. The PSKs that get provisioned
are the ones that are easy to enter with a low probability of error-- i.e.
something considerably less than uniformly random 128-bit key
generated from a good source of entropy.

  This is not (only) a theoretical issue. It's practical reality.

> Also, it should be noted that with this definition, the TLS session keys
> are
> vulnerable to a dictionary attack too. In practice, it's not a problem
> either
> for the same reason. Obviously the difference between the pre-shared key
> and the
> TLS session keys is that the later is short-term while the former is
> long-term.
> Which basically boils down to the point that PSK lacks FS.
>
> Are you sure you have point besides:
> - pre-shared key must be chosen with sufficient entropy and
> - PSK does not offer FS?

  Yes, I'm absolutely sure. It's:

  - you can't ensure security with MUSTs and SHALLs; and,
  - the use case that you say compels PSK ciphersuites actually argues
     against you.

TLS should be as misuse resistant as possible. That is, it should be as
hard as possible to use improperly and that means no PSK ciphersuites.

  regards,

  Dan.



From nobody Mon Oct 20 12:22:16 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4CD1A9218 for ; Mon, 20 Oct 2014 12:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level: 
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8k-LJ61rB7m for ; Mon, 20 Oct 2014 12:22:10 -0700 (PDT)
Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.212.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051621AC3BB for ; Mon, 20 Oct 2014 12:22:03 -0700 (PDT)
Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id E3B611699715D; Mon, 20 Oct 2014 14:22:00 -0500 (CDT)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 70CEB16996E45 for ; Mon, 20 Oct 2014 14:22:00 -0500 (CDT)
Received: from [198.180.150.142] (port=50719 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgIWl-00041g-K2 for tls@ietf.org; Mon, 20 Oct 2014 14:22:00 -0500
From: Sean Turner 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Mon, 20 Oct 2014 21:21:55 +0200
To: "TLS@ietf.org (tls@ietf.org)" 
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 198.180.150.142
X-Exim-ID: 1XgIWl-00041g-K2
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:50719
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 9
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BmVZf3-LX5oXnTV3mDfp0yuhwFs
Subject: [TLS] 20141021/22 TLS Interim: Remote Participant Details
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 19:22:13 -0000

All,

The interim meeting is scheduled for:
2014-10-21 from 9am-4pm
2014-10-22 from 9am-4pm
Please note that this is CEST =3D Central European Summer Time UTC =
+02:00

All participants are bound by the note well:
http://www.ietf.org/about/note-well.html

The proceedings (agenda, minutes, proceedings) can be found here (look =
for the 2014-10-21 tls row):
https://www.ietf.org/meeting/interim/proceedings.html =20

The only slides uploaded so far are the administrivia slides.  As/If I =
receive slides decks, I=92ll upload them.

For those participating remotely, a TLS jabber room is available as well =
as a Webex session; details follow:

1) Jabber

tls@jabber.ietf.org

Will will draft a jabber scribe to make sure remote questions/comments =
are channeled in to the room.  The scribe will likely not provide a =
transcription of the conversations at the interim but will make sure =
remote participants are at a minimum kept abreast of what topic/slide is =
being discussed.

NOTE: The jabber room logs are archived.

2) Webex (I hope this works)

NOTE: If you are not speaking please *MUTE* your phone to minimize the =
chance for disruptions during the call.

NOTE: Webex has a chat facility too, but it=92s probably best to use the =
tis@jabber.ietf.org room instead.

IMPORTANT NOTICE: This WebEx service includes a feature that allows =
audio and any documents and other materials exchanged or viewed during =
the session to be recorded. By joining this session, you automatically =
consent to such recordings. If you do not consent to the recording, =
discuss your concerns with the meeting host prior to the start of the =
recording or do not join the session. Please note that any such =
recordings may be subject to discovery in the event of litigation.

TLS Interim Meeting
Tuesday, October 21, 2014 & Wednesday, October 22, 2014
9:00 am  |  Europe Summer Time (Paris, GMT+02:00)

Join WebEx meeting
Meeting number:	641 550 329
Meeting password:	1234

Join by phone:
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 641 550 329

spt=


From nobody Mon Oct 20 12:31:53 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E797D1AC41B for ; Mon, 20 Oct 2014 12:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lz0TNrETvmIx for ; Mon, 20 Oct 2014 12:31:47 -0700 (PDT)
Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40ED91AC412 for ; Mon, 20 Oct 2014 12:31:47 -0700 (PDT)
Received: by mail-yh0-f44.google.com with SMTP id i57so3815544yha.3 for ; Mon, 20 Oct 2014 12:31:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tUvvk09NBB20Tm0RsgKaMkRHMqgNLThIj1MGK/fX0MU=; b=ML3dNVHw7h8/YwFJIjx74qcYQVTJN462STevLv6aHKkdZnr3pJgcrWGJ0ZXWMqxzs6 oVdD7zEnzig/kUCOORNYjBhp0+op7qc+eJYr7Q0w2CI6iXVcY2+JqZW/417Y3QWNVDI5 2G0KNCvdrbSQAmOIaJx1k26E33DpFtD0NueMjh1Kuqt0rX4t4dMeWegt/79tMNlKx7t2 qYhBng8vLj1poCJvngSThqPvb4b1mLTwNN6brsHwTSsFWEg+hzlP+xQ0lf+vgtuc+kJv InBmxXljNss20zWr5ww0/qZ7CAc95ukd4WaxHnhgIk6dAM8LZWgdYvdTFX6x1EF2b2tN 7fJA==
MIME-Version: 1.0
X-Received: by 10.236.30.197 with SMTP id k45mr5662084yha.163.1413833506472; Mon, 20 Oct 2014 12:31:46 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Mon, 20 Oct 2014 12:31:45 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Mon, 20 Oct 2014 12:31:45 -0700 (PDT)
In-Reply-To: 
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net>  <74986741b83a76277b2fcfd1e74a75d4.squirrel@www.trepanning.net> <54454F3C.7010305@polarssl.org>  
Date: Mon, 20 Oct 2014 12:31:45 -0700
Message-ID: 
From: Watson Ladd 
To: Dan Harkins 
Content-Type: multipart/alternative; boundary=089e01634d34eccb9e0505dfc389
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q0342OFkkFlhpTr240YZ3pg0Pag
Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , tls@ietf.org
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 19:31:50 -0000

--089e01634d34eccb9e0505dfc389
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Oct 20, 2014 12:20 PM, "Dan Harkins"  wrote:
>
>
> On Mon, October 20, 2014 11:06 am, Manuel P=C3=A9gouri=C3=A9-Gonnard wrot=
e:
> > On 20/10/2014 19:06, Dan Harkins wrote:
> >>   There is nothing to flesh out because you seem to not understand
> >> what a dictionary attack is-- but you're in company because neither
> >> did the editors of that RFC.
> >>
> >>   Protocols that use a static, symmetric credential like a PSK (or a
> >> password, the difference is semantic) are all flawed because the
> >> adversary is always assumed to have access to a pool from which
> >> the PSK (or password is drawn. Resistance against dictionary attack
> >> is then a demonstration that the advantage gained by the adversary
> >> is due to _interaction_ and not _computation_.
> >>
> >>   Merely making the pool from which the PSK is drawn, for instance
> >> by making it a bigger or including mixed case, etc, does not make
> >> the protocol resistant to dictionary attack.
> >
> > From a theoretical standpoint, the PSK key exchange is indeed vulnerabl=
e
> > to a
> > dictionary attack with this definition. In practice, if your keys are
> > 128-bit
> > long and chosen uniformly at random using a good source of entropy, I
> > doubt any
> > real-world adversary is able to gain a non-negligible advantage in the
> > foreseeable future.
>
>   The justification for these ciphersuites is some constrained device tha=
t
> has a small data and code size. But if you can not only generate 128-bit
> long uniformly random keys from a good source of entropy and also
> securely provision them on 2 (or more) devices then you don't need TLS.
> Just do static keyed symmetric crypto and you save even more data
> and code by eliminating TLS!
>
>   In practice, these things are deployed by people who probably do not
> read the RFC in question, are in a hurry, and don't understand the
> security implications of their use of TLS. The PSKs that get provisioned
> are the ones that are easy to enter with a low probability of error-- i.e=
.
> something considerably less than uniformly random 128-bit key
> generated from a good source of entropy.
>
>   This is not (only) a theoretical issue. It's practical reality.

I dissent here: interoperability and firewall traversal are good reasons
not to homebake something, and if this WG had done it's job, security would
likely be better then a home brewed protocol.
>
> > Also, it should be noted that with this definition, the TLS session key=
s
> > are
> > vulnerable to a dictionary attack too. In practice, it's not a problem
> > either
> > for the same reason. Obviously the difference between the pre-shared ke=
y
> > and the
> > TLS session keys is that the later is short-term while the former is
> > long-term.
> > Which basically boils down to the point that PSK lacks FS.
> >
> > Are you sure you have point besides:
> > - pre-shared key must be chosen with sufficient entropy and
> > - PSK does not offer FS?
>
>   Yes, I'm absolutely sure. It's:
>
>   - you can't ensure security with MUSTs and SHALLs; and,
>   - the use case that you say compels PSK ciphersuites actually argues
>      against you.
>
> TLS should be as misuse resistant as possible. That is, it should be as
> hard as possible to use improperly and that means no PSK ciphersuites.

I concurr.
>
>   regards,
>
>   Dan.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--089e01634d34eccb9e0505dfc389
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Oct 20, 2014 12:20 PM, "Dan Harkins" <dharkins@lounge.org> wrote:

>

>

> On Mon, October 20, 2014 11:06 am, Manuel P=C3=A9gouri=C3=A9-Gonnard w=
rote:

> > On 20/10/2014 19:06, Dan Harkins wrote:

> >>=C2=A0 =C2=A0There is nothing to flesh out because you seem to=
 not understand

> >> what a dictionary attack is-- but you're in company becau=
se neither

> >> did the editors of that RFC.

> >>

> >>=C2=A0 =C2=A0Protocols that use a static, symmetric credential=
 like a PSK (or a

> >> password, the difference is semantic) are all flawed because =
the

> >> adversary is always assumed to have access to a pool from whi=
ch

> >> the PSK (or password is drawn. Resistance against dictionary =
attack

> >> is then a demonstration that the advantage gained by the adve=
rsary

> >> is due to _interaction_ and not _computation_.

> >>

> >>=C2=A0 =C2=A0Merely making the pool from which the PSK is draw=
n, for instance

> >> by making it a bigger or including mixed case, etc, does not =
make

> >> the protocol resistant to dictionary attack.

> >

> > From a theoretical standpoint, the PSK key exchange is indeed vul=
nerable

> > to a

> > dictionary attack with this definition. In practice, if your keys=
 are

> > 128-bit

> > long and chosen uniformly at random using a good source of entrop=
y, I

> > doubt any

> > real-world adversary is able to gain a non-negligible advantage i=
n the

> > foreseeable future.

>

> =C2=A0 The justification for these ciphersuites is some constrained de=
vice that

> has a small data and code size. But if you can not only generate 128-b=
it

> long uniformly random keys from a good source of entropy and also

> securely provision them on 2 (or more) devices then you don't need=
 TLS.

> Just do static keyed symmetric crypto and you save even more data

> and code by eliminating TLS!

>

> =C2=A0 In practice, these things are deployed by people who probably d=
o not

> read the RFC in question, are in a hurry, and don't understand the=


> security implications of their use of TLS. The PSKs that get provision=
ed

> are the ones that are easy to enter with a low probability of error-- =
i.e.

> something considerably less than uniformly random 128-bit key

> generated from a good source of entropy.

>

> =C2=A0 This is not (only) a theoretical issue. It's practical real=
ity.


I dissent here: interoperability and firewall traversal are =
good reasons not to homebake something, and if this WG had done it's jo=
b, security would likely be better then a home brewed protocol. 

>

> > Also, it should be noted that with this definition, the TLS sessi=
on keys

> > are

> > vulnerable to a dictionary attack too. In practice, it's not =
a problem

> > either

> > for the same reason. Obviously the difference between the pre-sha=
red key

> > and the

> > TLS session keys is that the later is short-term while the former=
 is

> > long-term.

> > Which basically boils down to the point that PSK lacks FS.

> >

> > Are you sure you have point besides:

> > - pre-shared key must be chosen with sufficient entropy and

> > - PSK does not offer FS?

>

> =C2=A0 Yes, I'm absolutely sure. It's:

>

> =C2=A0 - you can't ensure security with MUSTs and SHALLs; and,

> =C2=A0 - the use case that you say compels PSK ciphersuites actually a=
rgues

> =C2=A0 =C2=A0 =C2=A0against you.

>

> TLS should be as misuse resistant as possible. That is, it should be a=
s

> hard as possible to use improperly and that means no PSK ciphersuites.=



I concurr.

>

> =C2=A0 regards,

>

> =C2=A0 Dan.

>

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf=
.org/mailman/listinfo/tls




--089e01634d34eccb9e0505dfc389--


From nobody Mon Oct 20 13:01:12 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AFD1ACD9B for ; Mon, 20 Oct 2014 13:01:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwoUAse07vPf for ; Mon, 20 Oct 2014 13:01:06 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917B81ACD9C for ; Mon, 20 Oct 2014 13:01:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413835263; x=1445371263; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=dWL2qiJ+aETU4iyUVRc5spoYlqfzRRXWj8CWDeY7fwk=; b=l/m5CJaB7RHDleZIreDxdM8gDaewyKBXr/1q1TQlA9iWo1FMnRa0om/A fHN/++jgyLdPz7AbS22P/hUVRujN2nM0SZO8dwVeQYf5SH5j9pK9DS6wF TX90rkqaayzu2url2vlazAeT9agYn/XPvPH/rIN23kb0ok//s1Q1/dIMA c=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="284477897"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Oct 2014 09:01:01 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 09:00:59 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] PSK in 1.3?
Thread-Index: Ac/soJElPqXqnehFQv+9v9F5KIzHAw==
Date: Mon, 20 Oct 2014 20:00:59 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D3EAE@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oO8YSsApVm9o7d30UGZ10qMHqIg
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 20:01:10 -0000

Dan Harkins  writes:=0A=
=0A=
>There is nothing to flesh out because you seem to not understand what a=0A=
>dictionary attack is-- but you're in company because neither did the edito=
rs=0A=
>of that RFC.=0A=
>=0A=
>Protocols that use a static, symmetric credential like a PSK (or a passwor=
d,=0A=
>the difference is semantic) are all flawed because the adversary is always=
=0A=
>assumed to have access to a pool from which the PSK (or password is drawn.=
=0A=
=0A=
As Watson has already pointed out, the protocol name is "preshared key", no=
t=0A=
"preshared password" as you seem to think.  I've been party to the deployme=
nt=0A=
of several PSK-based devices/systems, for which the pool from which the PSK=
 is=0A=
drawn is well-known to an attacker, it ranges from 00 00 00 00 00 00 00 00 =
00=0A=
00 00 00 00 00 00 to FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF.  Sinc=
e=0A=
I've now given you what you need to know, I'll let you go away and brute-fo=
rce=0A=
the system.  Let us know when you're done.=0A=
=0A=
Peter.=


From nobody Mon Oct 20 13:12:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E121A9107 for ; Mon, 20 Oct 2014 13:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFpflz91RDDz for ; Mon, 20 Oct 2014 13:12:28 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B417C1ACD91 for ; Mon, 20 Oct 2014 13:12:27 -0700 (PDT)
Received: from mail-yh0-f53.google.com (mail-yh0-f53.google.com [209.85.213.53]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0LnX58-1YLhXt0aCc-00hiSU; Mon, 20 Oct 2014 22:12:23 +0200
Received: by mail-yh0-f53.google.com with SMTP id b6so3898386yha.12 for ; Mon, 20 Oct 2014 13:12:21 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.231.116 with SMTP id k110mr7534857yhq.127.1413835941894;  Mon, 20 Oct 2014 13:12:21 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Mon, 20 Oct 2014 13:12:21 -0700 (PDT)
In-Reply-To: <460682079.47331533.1413825491684.JavaMail.zimbra@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>  <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com>  <1413807699.2597.14.camel@dhcp-2-127.brq.redhat.com>  <460682079.47331533.1413825491684.JavaMail.zimbra@redhat.com>
Date: Mon, 20 Oct 2014 22:12:21 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0160a27416636e0505e0556a
X-Provags-ID: V02:K0:h/PLGyBVSmDbQnz4fPXXRH9Wi8qrudJsziJuEghHO+8 34aVZLAG/2KIU3P0QCkNI1W9qSUZvxcLR5HmIujII6WmDAGrMO SxJs6VG6tk63RTh3O+/9sr7kHymMLTCXlZOoXdpmYdipre8vjY qiUxh53gxFmiwabU5xuZJSj5ELQ3yAu6jcXcUZvAj8PkXPpVQt GAY6j2YNVWk5k9C2DlKK7fU6GYxKQ7s/YtYIETf0Piu89zJBy4 lJW7Z3mDszpc3sbcdnhdnU8egyjUUykLkc4Gq+AmAPWyTUBSxy QS+sqXe6OKROJ9/WDMPm+kR7FclySyRvsjjxNQLBxdd/sesx60 yQstjnyj9BKXixVppTZObOSUbb4Olgk4Dak+cEb0gr8KGwiAyz 2RptMVbZy7cbsZEazBDl3WwVfjRM26LuYCT1OPV5Jp3iiRgvJc J4JFI
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tcMFVG_gZLr4BIGrKlPwAqq5Vxw
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 20:12:29 -0000

--089e0160a27416636e0505e0556a
Content-Type: text/plain; charset=UTF-8

Nikos Mavrogiannopoulos :

With this change, clients still consider the servers that
> require a downgrade dance secure. Why should that be the case? Why for
> example
> chrome or firefox doesn't warn on these servers? They are certainly not
> secure.
>

I'm not sure why you think that the TLS_FALLBACK_SCSV specification should
be setting UI requirements for this. The same protocol versions, negotiated
using the normal version negotiation mechanism, are just as secure or
insecure, so this isn't specific to TLS_FALLBACK_SCSV.

Bodo

--089e0160a27416636e0505e0556a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Niko=
s Mavrogiannopoulos <nmav@redhat.com>:

With this change, clients still consider the servers that

require a downgrade dance secure. Why should that be the case? Why for exam=
ple

chrome or firefox doesn't warn on these servers? They are certainly not=


secure.

I'm not sure why you think =
that the TLS_FALLBACK_SCSV specification should be setting UI requirements =
for this. The same protocol versions, negotiated using the normal version n=
egotiation mechanism, are just as secure or insecure, so this isn't spe=
cific to TLS_FALLBACK_SCSV.

Bodo



--089e0160a27416636e0505e0556a--


From nobody Mon Oct 20 13:13:04 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55541ACDC3 for ; Mon, 20 Oct 2014 13:13:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qf6TtPfYBu1 for ; Mon, 20 Oct 2014 13:13:00 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id B43A41ACDAF for ; Mon, 20 Oct 2014 13:13:00 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D9AE5165800 for ; Mon, 20 Oct 2014 20:12:59 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id CED4D1657FC for ; Mon, 20 Oct 2014 20:12:59 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 9C1D11E03E for ; Mon, 20 Oct 2014 20:12:59 +0000 (GMT)
Received: from usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 20 Oct 2014 16:12:59 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Mon, 20 Oct 2014 16:12:58 -0400
From: "Salz, Rich" 
To: "TLS@ietf.org (tls@ietf.org)" 
Date: Mon, 20 Oct 2014 16:11:21 -0400
Thread-Topic: Unifying tickets and sessions
Thread-Index: Ac/soXv8r4hf3UNsSPSgto+m1gTrLg==
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MwDBl_W4zsplgNUI7AaG_rRiKx8
Subject: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 20:13:02 -0000

It's proposed that we unify tickets and sessions at the protocol level.

--------------------------------

For 1.3 we bring in the extension definitions from 5077. For the wire forma=
t, it doesn't matter if the information is a session identifier (a short st=
ring, referring to state maintained on the server) or a ticket (the actual =
crypto state, stored on the client). Perhaps to be general, we call it sess=
ion token.

A TLS 1.3 client MUST send an empty session_id field. It may send a ticket =
extension. If the server is willing to accept the crypto state, it sends a =
"1" in the returned session_id field, otherwise it sends an empty session_i=
d. This is the only use of session_id in TLS 1.3.

The session token may either be an opaque identifier of local server state,=
 or a serialization of the state the server needs, encrypted with some key.=
 General security considerations require that this information not be kept =
on long-lived media, and that the identifier or encryption key be rotated p=
eriodically. These are server-side implementation details.

The session token can be used to tie together multiple transactions with a =
loss of forward secrecy. Clients can always omit the session token. Servers=
 SHOULD set the lifetime to an appropriate value (and MUST NOT be more than=
 nn hours).  [Where nn is TBD; either 24 or 48.]

"MUST NOT" for more than 24 hours seems to strict. If you rotate keys every=
 24 hours, session tickets end up being valid for up to 2 * 24 hours (+ fud=
ge) unless you start to reject them while the server still has the key, whi=
ch seems pointless. Depending on how you set up cron, that could be 49 hour=
s+ in practice due to DST.



From nobody Mon Oct 20 13:26:55 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D22B1ACDF4 for ; Mon, 20 Oct 2014 13:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q30hmqtlrn4m for ; Mon, 20 Oct 2014 13:26:50 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3FB1ACDFA for ; Mon, 20 Oct 2014 13:26:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=7MUp7p7qbWjzFUGIjkq3pofDYSAPlM7ezPozeqcGN0w=;  b=f+FOeJlO5ygGUcqwjOWzeVdN1BOGC+pWAu4iRUOOykc/4DLQKUULJZD3BTBh3DO2FPqAnRJflgh62yIk+C3vfo/lDYLDzDHBdYcvbxgntorV7smTbXgLKZuKBI1b2ohhNII3cQPkYDka/XiUwb5FJDtm39OJObvIxIiENFyZP5I=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgJXO-000481-1p; Mon, 20 Oct 2014 22:26:42 +0200
Message-ID: <54457005.3040107@polarssl.org>
Date: Mon, 20 Oct 2014 22:26:45 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Dan Harkins 
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net>  <74986741b83a76277b2fcfd1e74a75d4.squirrel@www.trepanning.net> <54454F3C.7010305@polarssl.org> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vw80w0uPWoT4JOAtxb-F3ZOPG14
Cc: "tls@ietf.org" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 20:26:53 -0000

On 20/10/2014 21:20, Dan Harkins wrote:
>   The justification for these ciphersuites is some constrained device that
> has a small data and code size. But if you can not only generate 128-bit
> long uniformly random keys from a good source of entropy and also
> securely provision them on 2 (or more) devices then you don't need TLS.
> Just do static keyed symmetric crypto and you save even more data
> and code by eliminating TLS!
> 
In addition to what Watson said, it's generally a bad idea to roll one's own
crypto protocol, it's too easy to get things wrong. Even with PSK, TLS brings
you important things: a record protocol, a way to derive session keys from the
long-term secret key, etc.

>   In practice, these things are deployed by people who probably do not
> read the RFC in question, are in a hurry, and don't understand the
> security implications of their use of TLS. The PSKs that get provisioned
> are the ones that are easy to enter with a low probability of error-- i.e.
> something considerably less than uniformly random 128-bit key
> generated from a good source of entropy.
> 
I agree that's a real problem. But I don't think it has anything to do with your
previous definition of dictionary attack. As you said earlier, the size of the
pool from which the key is drawn does not change the fact the a protocol is or
isn't resistant to dictionary attack. My impression is that the size of the pool
(or more precisely the entropy of the key generator) is exactly the problem (and
from my understanding of your previous paragraph, we at least agree that it's an
important question).

>   - you can't ensure security with MUSTs and SHALLs; and,

That's one point I certainly agree with.

> TLS should be as misuse resistant as possible. That is, it should be as
> hard as possible to use improperly and that means no PSK ciphersuites.
> 
I agree about misuse resistance, and I agree it's a serious problem with the PSK
ciphersuites. I'm just not sure if it's serious enough to get rid of them.

I'd like to point out again that, in contrast with the NULL ciphersuites for
example, the mere existence of the PSK suites is less of a threat for the rest
of TLS, since there is very little risk of them being silently selected by
mistake. The problem is people who choose to use PSK but do it badly, but it
does not affect people who don't choose to use PSK.

Anyway, it's good to be discussing this explicitly.

Manuel.


From nobody Mon Oct 20 13:34:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6665A1ACE33 for ; Mon, 20 Oct 2014 13:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2eoZNWgPkdu for ; Mon, 20 Oct 2014 13:34:38 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id DDCC31ACE31 for ; Mon, 20 Oct 2014 13:34:38 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6129910224008; Mon, 20 Oct 2014 13:34:37 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 20 Oct 2014 13:34:38 -0700 (PDT)
Message-ID: <96b88d73f776e16e3f5487643fb59a31.squirrel@www.trepanning.net>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9D3EAE@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D3EAE@uxcn10-5.UoA.auckland.ac.nz>
Date: Mon, 20 Oct 2014 13:34:38 -0700 (PDT)
From: "Dan Harkins" 
To: "Peter Gutmann" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IP6s3t0W-b5MViVJsnbnyXiL-N0
Cc: tls@ietf.org
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 20:34:42 -0000

On Mon, October 20, 2014 1:00 pm, Peter Gutmann wrote:
> Dan Harkins  writes:
>
>>There is nothing to flesh out because you seem to not understand what a
>>dictionary attack is-- but you're in company because neither did the
>> editors
>>of that RFC.
>>
>>Protocols that use a static, symmetric credential like a PSK (or a
>> password,
>>the difference is semantic) are all flawed because the adversary is
>> always
>>assumed to have access to a pool from which the PSK (or password is
>> drawn.
>
> As Watson has already pointed out, the protocol name is "preshared key",
> not
> "preshared password" as you seem to think.  I've been party to the
> deployment
> of several PSK-based devices/systems, for which the pool from which the
> PSK is
> drawn is well-known to an attacker, it ranges from 00 00 00 00 00 00 00 00
> 00
> 00 00 00 00 00 00 to FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF.
> Since
> I've now given you what you need to know, I'll let you go away and
> brute-force
> the system.  Let us know when you're done.

  Is that the "royal we"?

  And, you need to supply a bit more than that information to enable
a dictionary attack (such as the data that contains a hash of the PSK plus
other information known to the attacker). But you were making a sarcastic
point, not a technical point weren't you?

  The issue is not so much the range, it's which values in that range are
going to be valid PSKs and which are not. But, again, you were being
sarcastic so a technical response is somewhat unnecessary.

  And, yes, I did notice that Watson said that the RFC is "pre-shared key"
and not "pre-shared password" but, as I said (did you notice?), that is
merely a semantic difference. The ciphersuites are _completely oblivious_
to the type and quality of the credential they use. You can't claim the
_protocol_ is resistent to dictionary attack if the protocol can be used
in a manner that makes it susceptible to dictionary attack.

  I have witnessed, and sadly been party to, many deployments of PSK-based
devices/systems for which the pool that the PSK is drawn from is the same
pool as you describe above. Unfortunately, they did something like
PBKDF2(easy-to-enter-keystream) to generate this PSK, which is not a
"password", in this huge range. And I encourage you to search the
Internet for "coWPAtty" to get a nice tool to attack them. Of course, you
will need to also supply a tcpdump of the exchange but that's easy to
capture.

  regards,

  Dan.



From nobody Mon Oct 20 13:44:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F891ACE71 for ; Mon, 20 Oct 2014 13:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPg8IkOkc7Px for ; Mon, 20 Oct 2014 13:44:08 -0700 (PDT)
Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7B1B1ACE69 for ; Mon, 20 Oct 2014 13:44:06 -0700 (PDT)
Received: by mail-yh0-f48.google.com with SMTP id v1so3938688yhn.7 for ; Mon, 20 Oct 2014 13:44:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rMtoadgxtk7+Q/x5A+49U6lkVE7D/4+ePKq3WXFEOuE=; b=aEIqOT35Hm5YHp2yQPMHQpZHBzn1T2XcPsVGyG5Vul0bwu+jKnEOBcZJkJDw5E1J6B 3ENdBckBcTR3mHAh66I+bGVPDxMQ1+V1efmNMlGiaUOdPCaNMZQcLD+gm1VH9ecxQj3S U28O70MuevvcgtE6WfAeBXXS2EH1/WsyLgho3NGR2nrAztoRgLs+3GbUWvjiRmOdTsqw C3ZuTXLZiZF5Oa0YeXl38wQFq9+38GXA8MkRJT68cJiXVKtRm0LZzun4jBbwzbPXpyeb Qnzv5UULqou+3Gfsfl6HZ2LNw0ggVPdTPijUZsTTJC7vOo4g6/sNsi8GL4Sovh0/iwB+ 9/jg==
MIME-Version: 1.0
X-Received: by 10.52.106.75 with SMTP id gs11mr21145612vdb.0.1413837846095; Mon, 20 Oct 2014 13:44:06 -0700 (PDT)
Received: by 10.220.58.136 with HTTP; Mon, 20 Oct 2014 13:44:05 -0700 (PDT)
In-Reply-To: 
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net>  <74986741b83a76277b2fcfd1e74a75d4.squirrel@www.trepanning.net> <54454F3C.7010305@polarssl.org> 
Date: Tue, 21 Oct 2014 00:44:05 +0400
Message-ID: 
From: Mohamad Badra 
To: Dan Harkins 
Content-Type: multipart/alternative; boundary=001a1133cdec962de60505e0c62a
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/es5HGPUT7WNBMZHUy8OV2PlvsUs
Cc: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9=2DGonnard?= , "tls@ietf.org" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 20:44:10 -0000

--001a1133cdec962de60505e0c62a
Content-Type: text/plain; charset=ISO-8859-1

>
>
>   The justification for these ciphersuites is some constrained device that
> has a small data and code size. But if you can not only generate 128-bit
> long uniformly random keys from a good source of entropy and also
> securely provision them on 2 (or more) devices then you don't need TLS.
> Just do static keyed symmetric crypto and you save even more data
> and code by eliminating TLS!
>
>   In practice, these things are deployed by people who probably do not
> read the RFC in question, are in a hurry, and don't understand the
> security implications of their use of TLS. The PSKs that get provisioned
> are the ones that are easy to enter with a low probability of error-- i.e.
> something considerably less than uniformly random 128-bit key
> generated from a good source of entropy.
>
>   This is not (only) a theoretical issue. It's practical reality.
>
>
Any link to sources that support this practical reality? Or it is a
theoretical statement?

Best regards
Badra

--001a1133cdec962de60505e0c62a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




=A0 The justification for these ciphersuites is some constrained dev=
ice that

has a small data and code size. But if you can not only generate 128-bit
long uniformly random keys from a good source of entropy and also

securely provision them on 2 (or more) devices then you don't need TLS.=


Just do static keyed symmetric crypto and you save even more data

and code by eliminating TLS!



=A0 In practice, these things are deployed by people who probably do not
read the RFC in question, are in a hurry, and don't understand the

security implications of their use of TLS. The PSKs that get provisioned
are the ones that are easy to enter with a low probability of error-- i.e.<=
br>
something considerably less than uniformly random 128-bit key

generated from a good source of entropy.



=A0 This is not (only) a theoretical issue. It's practical reality.



Any link to so=
urces that support this practical reality? Or it is a theoretical statement=
?

Best regards
Badra


--001a1133cdec962de60505e0c62a--


From nobody Mon Oct 20 13:52:23 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28841A0105 for ; Mon, 20 Oct 2014 13:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGR9rIKA-tDs for ; Mon, 20 Oct 2014 13:52:17 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972061A1ADF for ; Mon, 20 Oct 2014 13:52:17 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Mon, 20 Oct 2014 20:52:15 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Mon, 20 Oct 2014 20:52:15 +0000
From: Andrei Popov 
To: Hubert Kario 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: AQHP6g/vkqpMmvBKoUCxL3G2jHnzlpw0TqsAgABoBICAAAgfwIAACI2AgAAH2aCAACaKgIAAAF8ggAAHRICAAAleYK+wogZE0FPRwjA=
Date: Mon, 20 Oct 2014 20:52:15 +0000
Message-ID: <95e6d46442e24f7dbc6151e2cce9d14f@BL2PR03MB419.namprd03.prod.outlook.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>   <7fe248e5b4374fbd8d04ff460bc3ace8@BL2PR03MB419.namprd03.prod.outlook.com> <76533ab02b644597a170cb5b76a42a99@BY2PR03MB554.namprd03.prod.outlook.com>   <8f805ba832b645e680bb5aba5b878265@BL2PR03MB419.namprd03.prod.outlook.com> <2063553608.14767069.1413800030437.JavaMail.zimbra@redhat.com>
In-Reply-To: <2063553608.14767069.1413800030437.JavaMail.zimbra@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB419;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 03706074BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(252514010)(13464003)(51704005)(199003)(377454003)(189002)(76576001)(105586002)(31966008)(97736003)(95666004)(33646002)(107046002)(15974865002)(74316001)(99286002)(120916001)(110136001)(99396003)(106116001)(76482002)(86362001)(106356001)(85852003)(19580395003)(19580405001)(54356999)(50986999)(76176999)(87936001)(2656002)(108616004)(92566001)(4396001)(85306004)(230783001)(93886004)(122556002)(40100003)(86612001)(46102003)(64706001)(80022003)(21056001)(101416001)(20776003)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5XVFI-qGO3OA0McTnBa-qlWubPU
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 20:52:20 -0000

Pj4gT24gdGhlIHNlcnZlciBzaWRlLCBTQ1NWIChub3QgZXh0ZW5zaW9uKSBpcyBvbmx5IG5lZWRl
ZCBpZiBhKSBTU0wzIGlzIA0KPj4gZW5hYmxlZCwgYW5kIGIpIHRoZSBzZXJ2ZXIgdHJpZXMgdG8g
cHJvdGVjdCBjbGllbnRzIHRoYXQgb2ZmZXIgVExTMS4wIA0KPj4gKG5vdA0KPj4gMS4xIG9yIDEu
MikgYXQgdGhlIGZpcnN0IGNvbm5lY3Rpb24gYXR0ZW1wdC4gQW0gSSBtaXNzaW5nIHNvbWV0aGlu
Zz8NCg0KPjEuMyB0byAxLjIuIE92ZXIgMTAlIG9mIEludGVybmV0IHdlYiBzZXJ2ZXJzIGFyZSBp
bnRvbGVyYW50IHRvIDEuMyBDbGllbnRIZWxsbw0KDQoxLjMgdG8gMS4yIGNvdWxkIGJlIHByb3Rl
Y3RlZCBieSBhbiBleHRlbnNpb247IEkgdGhpbmsgU0NTViBpcyBvbmx5IG5lZWRlZCB0byBwcm90
ZWN0IHRoZSBkb3duZ3JhZGUgZnJvbSBUTFMxLjAgdG8gU1NMMy4NCg0KQ2hlZXJzLA0KDQpBbmRy
ZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEh1YmVydCBLYXJpbyBbbWFp
bHRvOmhrYXJpb0ByZWRoYXQuY29tXSANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMCwgMjAxNCAz
OjE0IEFNDQpUbzogQW5kcmVpIFBvcG92DQpDYzogTWFydGluIFRob21zb247IHRsc0BpZXRmLm9y
Zw0KU3ViamVjdDogUmU6IFtUTFNdIFRoZSBUTFNfRkFMTEJBQ0tfU0NTViB0aW1lIGJvbWIgKHdh
czogUmU6IFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLXRscy1kb3duZ3Jh
ZGUtc2Nzdi0wMCkNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiQW5k
cmVpIFBvcG92IiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQo+IFRvOiAiTWFydGluIFRo
b21zb24iIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQo+IENjOiB0bHNAaWV0Zi5vcmcNCj4g
U2VudDogU2F0dXJkYXksIDE4IE9jdG9iZXIsIDIwMTQgMzowODoyMCBBTQ0KPiBTdWJqZWN0OiBS
ZTogW1RMU10gVGhlIFRMU19GQUxMQkFDS19TQ1NWIHRpbWUgYm9tYiAod2FzOiBSZTogV29ya2lu
ZyANCj4gR3JvdXAgTGFzdCBDYWxsIGZvcg0KPiBkcmFmdC1pZXRmLXRscy1kb3duZ3JhZGUtc2Nz
di0wMCkNCj4gDQo+IENlcnRhaW5seSBhIGxvdCBvZiBpbXBsZW1lbnRhdGlvbnMgd2lsbCBrZWVw
IFNTTDMgY29kZSBhcm91bmQgZm9yIGEgDQo+IHdoaWxlLCBqdXN0IGRpc2FibGVkIGJ5IGRlZmF1
bHQuDQo+IA0KPiBPbiB0aGUgY2xpZW50IHNpZGUsIFNDU1YgKG5vdCBleHRlbnNpb24pIGlzIG9u
bHkgbmVlZGVkIGlmIGZhbGxiYWNrIHRvIA0KPiBTU0wzIGlzIGFsbG93ZWQsIGNvcnJlY3Q/IFRo
aXMgaXMgdGhlIHZlcnkgZmFsbGJhY2sgdGhhdCBicm93c2VyIA0KPiB2ZW5kb3JzIGFyZSBkaXNh
YmxpbmcgcmlnaHQgbm93LiBTbyB0aGUgb25seSBicm93c2VycyB0aGF0IGZhbGwgYmFjayANCj4g
dG8gU1NMMyB3aWxsIGJlIHRoZSBvbmVzIHdpdGhvdXQgdGhlIERvd25ncmFkZS1TQ1NWIHN1cHBv
cnQuDQoNCldlIGRvbid0IGtub3cgeWV0IGlmIGl0IHdpbGwgYmUgZGlzYWJsZWQgaW4gYWxsIGJy
b3dzZXJzLg0KDQo+IE9uIHRoZSBzZXJ2ZXIgc2lkZSwgU0NTViAobm90IGV4dGVuc2lvbikgaXMg
b25seSBuZWVkZWQgaWYgYSkgU1NMMyBpcyANCj4gZW5hYmxlZCwgYW5kIGIpIHRoZSBzZXJ2ZXIg
dHJpZXMgdG8gcHJvdGVjdCBjbGllbnRzIHRoYXQgb2ZmZXIgVExTMS4wIA0KPiAobm90DQo+IDEu
MSBvciAxLjIpIGF0IHRoZSBmaXJzdCBjb25uZWN0aW9uIGF0dGVtcHQuIEFtIEkgbWlzc2luZyBz
b21ldGhpbmc/DQoNCjEuMyB0byAxLjIuIE92ZXIgMTAlIG9mIEludGVybmV0IHdlYiBzZXJ2ZXJz
IGFyZSBpbnRvbGVyYW50IHRvIDEuMyBDbGllbnRIZWxsbw0KDQo+IEhvd2V2ZXIsIGEgYnJvd3Nl
ciB0aGF0IGltcGxlbWVudHMgYSBzaGlueSBuZXcgRG93bmdyYWRlLXNvbWV0aGluZyBSRkMgDQo+
IGlzIHVubGlrZWx5IHRvIG9mZmVyIFRMUzEuMCBvbiB0aGUgZmlyc3QgY29ubmVjdGlvbiBhdHRl
bXB0Lg0KDQpCcm93c2VycyBtYXliZSBub3QgKHRpbWUgd2lsbCB0ZWxsKSwgYnV0IGl0IGdvdCBp
bXBsZW1lbnRlZCBpbiBPcGVuU1NMIDAuOS44IHdoaWNoIHN1cHBvcnRzIFRMUyAxLjAgbWF4Lg0K
DQotLQ0KUmVnYXJkcywNCkh1YmVydCBLYXJpbw0KUXVhbGl0eSBFbmdpbmVlciwgUUUgQmFzZU9T
IFNlY3VyaXR5IHRlYW0NCkVtYWlsOiBoa2FyaW9AcmVkaGF0LmNvbQ0KV2ViOiB3d3cuY3oucmVk
aGF0LmNvbQ0KUmVkIEhhdCBDemVjaCBzLnIuby4sIFB1cmt5xYhvdmEgOTkvNzEsIDYxMiA0NSwg
QnJubywgQ3plY2ggUmVwdWJsaWMNCg==


From nobody Mon Oct 20 13:58:37 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672481ACE82 for ; Mon, 20 Oct 2014 13:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxDvU2jxO3JN for ; Mon, 20 Oct 2014 13:58:33 -0700 (PDT)
Received: from mx204.easyname.com (mx204.easyname.com [212.232.28.125]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE47A1ACE75 for ; Mon, 20 Oct 2014 13:58:32 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgK26-0006fx-4N; Mon, 20 Oct 2014 22:58:28 +0200
Message-ID: <5445775E.3050108@fussenegger.info>
Date: Mon, 20 Oct 2014 22:58:06 +0200
From: "Richard Fussenegger, BSc" 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Salz, Rich" ,  "TLS@ietf.org (tls@ietf.org)" 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030309040101020205020100"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/modYI7q0O1XQt-OUad9QY9H3MHY
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 20:58:36 -0000

This is a cryptographically signed message in MIME format.

--------------ms030309040101020205020100
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

Nice to see this merge and I directly +1 the token wording.

How about **MUST NOT** for more than 24 hours for the encryption key and =

**MUST NOT** for more than 3 x 24 hours for decryption keys? That should =

account for all possibilities and one can use three keys to achieve it=20
that rotate at the same intervals.

The RFC should clarify that the negotiated cipher **MUST** be honored=20
when encrypting the state that will be sent to the client. [1]

Regards
Richard

[1] https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-WP.pdf

On 10/20/2014 10:11 PM, Salz, Rich wrote:
> It's proposed that we unify tickets and sessions at the protocol level.=

>
> --------------------------------
>
> For 1.3 we bring in the extension definitions from 5077. For the wire f=
ormat, it doesn't matter if the information is a session identifier (a sh=
ort string, referring to state maintained on the server) or a ticket (the=
 actual crypto state, stored on the client). Perhaps to be general, we ca=
ll it session token.
>
> A TLS 1.3 client MUST send an empty session_id field. It may send a tic=
ket extension. If the server is willing to accept the crypto state, it se=
nds a "1" in the returned session_id field, otherwise it sends an empty s=
ession_id. This is the only use of session_id in TLS 1.3.
>
> The session token may either be an opaque identifier of local server st=
ate, or a serialization of the state the server needs, encrypted with som=
e key. General security considerations require that this information not =
be kept on long-lived media, and that the identifier or encryption key be=
 rotated periodically. These are server-side implementation details.
>
> The session token can be used to tie together multiple transactions wit=
h a loss of forward secrecy. Clients can always omit the session token. S=
ervers SHOULD set the lifetime to an appropriate value (and MUST NOT be m=
ore than nn hours).  [Where nn is TBD; either 24 or 48.]
>
> "MUST NOT" for more than 24 hours seems to strict. If you rotate keys e=
very 24 hours, session tickets end up being valid for up to 2 * 24 hours =
(+ fudge) unless you start to reject them while the server still has the =
key, which seems pointless. Depending on how you set up cron, that could =
be 49 hours+ in practice due to DST.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



--------------ms030309040101020205020100
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjAyMDU4MDZaMCMGCSqGSIb3DQEJBDEWBBQaaEm+z/BwWAhoW+KKKHfaqbVl3jBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEAEd0X/mo9vBt8CsVfokJPUlz9PtkT
qgJiuI51xpwwhyVdgVU/oIzj57I1qywpS4SX/yTVaQ4pEd+8uiWQeKEw9ZR0zh7D/GlIuyrN
++IL3noMlx0sgYiDJsPDgIg8tEmNwivO3Idd/y54d/DVcZhCx3LTI+0MJdSh/qct7fDTmuHp
jp+lZIgy4iEDDIXVlRvrME0BJExXDSV65/kps8yJmOkmpCU+bkX/2jF1O61jMpmx4DFnHqNE
CNr3U+1bzA4iEAX4AzR332Vv9dqkrSLHGh9FFZy7hJxCtfObR5MlLJ6BgB+BFLlPxMgyVfX4
P6Yx5WhZlYzkKLMhwlbfeX8dXgAAAAAAAA==
--------------ms030309040101020205020100--


From nobody Mon Oct 20 14:02:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E501ACE9D for ; Mon, 20 Oct 2014 14:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DojBaHrFXPFX for ; Mon, 20 Oct 2014 14:02:07 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1211ACE72 for ; Mon, 20 Oct 2014 14:02:07 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 79345284E6; Mon, 20 Oct 2014 21:02:06 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 65F45284D5; Mon, 20 Oct 2014 21:02:06 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 30ABE2027; Mon, 20 Oct 2014 21:02:05 +0000 (GMT)
Received: from usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 20 Oct 2014 17:02:04 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 20 Oct 2014 17:02:04 -0400
From: "Salz, Rich" 
To: Andrei Popov , Hubert Kario 
Date: Mon, 20 Oct 2014 17:02:00 -0400
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: AQHP6g/vkqpMmvBKoUCxL3G2jHnzlpw0TqsAgABoBICAAAgfwIAACI2AgAAH2aCAACaKgIAAAF8ggAAHRICAAAleYK+wogZE0FPRwjCAAANGUA==
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4907@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>   <7fe248e5b4374fbd8d04ff460bc3ace8@BL2PR03MB419.namprd03.prod.outlook.com> <76533ab02b644597a170cb5b76a42a99@BY2PR03MB554.namprd03.prod.outlook.com>   <8f805ba832b645e680bb5aba5b878265@BL2PR03MB419.namprd03.prod.outlook.com> <2063553608.14767069.1413800030437.JavaMail.zimbra@redhat.com> <95e6d46442e24f7dbc6151e2cce9d14f@BL2PR03MB419.namprd03.prod.outlook.com>
In-Reply-To: <95e6d46442e24f7dbc6151e2cce9d14f@BL2PR03MB419.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8sDAyBEKdlcu2ShL9Qc5O_N8x2Y
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 21:02:08 -0000

PiA+MS4zIHRvIDEuMi4gT3ZlciAxMCUgb2YgSW50ZXJuZXQgd2ViIHNlcnZlcnMgYXJlIGludG9s
ZXJhbnQgdG8gMS4zDQo+ID5DbGllbnRIZWxsbw0KDQpTaHJ1Zywgc2luY2UgaXQncyBub3QgZGVm
aW5lZCBJIGRvbid0IHRoaW5rIGl0IG1hdHRlcnMgdGhhdCBtdWNoLg0KDQo+IDEuMyB0byAxLjIg
Y291bGQgYmUgcHJvdGVjdGVkIGJ5IGFuIGV4dGVuc2lvbjsgSSB0aGluayBTQ1NWIGlzIG9ubHkg
bmVlZGVkIHRvDQo+IHByb3RlY3QgdGhlIGRvd25ncmFkZSBmcm9tIFRMUzEuMCB0byBTU0wzLg0K
DQpJIHdvdWxkIHJhdGhlciBub3QgaGF2ZSB0d28gbWVjaGFuaXNtcyB0aGF0IGRvIHRoZSBleGFj
dCBzYW1lIHRoaW5nLg0KDQotLSAgDQpQcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXIsIEFrYW1h
aSBUZWNobm9sb2dpZXMNCklNOiByc2FsekBqYWJiZXIubWUgVHdpdHRlcjogUmljaFNhbHoNCg0K


From nobody Mon Oct 20 14:39:40 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5A91ACF07 for ; Mon, 20 Oct 2014 14:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.997
X-Spam-Level: 
X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_xXn3O8P-YX for ; Mon, 20 Oct 2014 14:39:37 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5851ACF04 for ; Mon, 20 Oct 2014 14:39:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=v3qHk4GAOJW4M4yyn5dZW9ZN/lS5dgVZE9D9tgmVEKM=;  b=C9MGxAXzK8ErnD+V6yC8kn8aWDA/R5xZIPezQYyHGflJ4fApdHmVyDtDTCWIwRPSulriU+6vBgi67Gqv/V44HcYlOSpIyrnEdUC2vJRbZrX2ifHhDX4+gpuFpaf2+Hf/wVS5UFplg953fDnXo/PjOx6g70K3au0c0vOi+QDsn6o=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgKfn-0004DA-Vk; Mon, 20 Oct 2014 23:39:28 +0200
Message-ID: <54458113.1050304@polarssl.org>
Date: Mon, 20 Oct 2014 23:39:31 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Richard Fussenegger, BSc" ,  "Salz, Rich" , "TLS@ietf.org (tls@ietf.org)" 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info>
In-Reply-To: <5445775E.3050108@fussenegger.info>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kUGK8h08LEpuuN1j9z-6tbpCF6s
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 21:39:39 -0000

On 20/10/2014 22:58, Richard Fussenegger, BSc wrote:
> Nice to see this merge and I directly +1 the token wording.
> 
++

> The RFC should clarify that the negotiated cipher **MUST** be honored 
> when encrypting the state that will be sent to the client. [1]
> 
While I'm sympathetic with the goal, I'm afraid that will complicate
implementations more than necessary. How about requiring to use a key length at
least a high as the highest supported ciphersuite instead?

One concern is that it's generally not recommended to use the same key with
different ciphers, so implementations would need to derive a key for each cipher
from a master key. That's certainly doable, but it adds a bit of complexity.

Another point is that we need to be sure that the same ciphersuite be selected
on resumption than on the original handshake. Since some extensions are needed
to choose the ciphersuite (at least SNI, signature_algorithms, the EC
extensions), it means those extensions need to be parsed before picking the
ciphersuite but the session_ticket extension after picking it. Nothing
insurmountable obviously, but again, complexity.

(Thinking while writing.) Perhaps more importantly, if a ciphersuite becomes
weak enough, an attacker could create tickets by forcing the server to
decrypt/authenticate them with the least secure ciphersuite it's willing to
accept, and use that to bypass client auth and.or mount other kind of attacks in
the server.

I'm not so sure the last paragraph is a real threat, but if it is, then it's
probably much safer to pick a single trusted cipher (or AEAD-cipher) and
conservative key size (such as 256 bits) for all tickets: of course it creates
an upper bound on the security of all sessions, but also a lower bound on ticket
authentication.

Manuel.


From nobody Mon Oct 20 15:23:44 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564221ACEEE for ; Mon, 20 Oct 2014 15:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vPksp6APUs8 for ; Mon, 20 Oct 2014 15:23:37 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:717]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B80C1ACE99 for ; Mon, 20 Oct 2014 15:23:37 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Mon, 20 Oct 2014 22:23:13 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Mon, 20 Oct 2014 22:23:13 +0000
From: Andrei Popov 
To: Peter Gutmann , "" 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: Ac/rUxJ+kqpMmvBKoUCxL3G2jHnzlgBVKtDw
Date: Mon, 20 Oct 2014 22:23:13 +0000
Message-ID: <71017e66b8ea43dea1e708e41b6aa93f@BL2PR03MB419.namprd03.prod.outlook.com>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D2991@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9D2991@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB418;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 03706074BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(13464003)(107046002)(107886001)(97736003)(74316001)(86612001)(76576001)(85306004)(105586002)(95666004)(54356999)(101416001)(76176999)(50986999)(106356001)(99286002)(108616004)(76482002)(40100003)(85852003)(120916001)(99396003)(92566001)(15975445006)(19580405001)(122556002)(19580395003)(87936001)(80022003)(46102003)(31966008)(2656002)(33646002)(230783001)(4396001)(21056001)(86362001)(20776003)(64706001)(24736002)(3826002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YH4UWKEletFnLLyt8CuW8Hl1IhI
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 22:23:40 -0000

> ... and 5,000 days for clients and servers where you have to wait for the=
 hardware to die in order to see an update.
You may be right; after all SSl2 is still deployed. My argument is about th=
e clients and servers that actually get regular updates. These up-to-date c=
lients are losing fallback to SSL3, so there's nothing to protect using SCS=
V (extension works fine for TLS1.0-1.3). These up-to-date servers negotiate=
 TLS1.2 with up-to-date clients, so there seems to be little need for them =
to protect TLS1.0 -> SSL3 downgrade.

> Oh, and given your affiliation, I was tempted to add: "So Microsoft are p=
lanning to roll out an update to Windows XP then?" :-).
Hopefully, POODLE will help bring about the end of XP :)

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Peter Gutmann
Sent: Saturday, October 18, 2014 9:14 PM
To: 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group =
Last Call for draft-ietf-tls-downgrade-scsv-00)

Andrei Popov  writes:

>I think about 60-90 days or so, for those clients and servers that get=20
>regular updates.

... and 5,000 days for clients and servers where you have to wait for the h=
ardware to die in order to see an update.

(10,000 days is probably on the long side, but I still have to maintain bac=
kwards-compatible bugfixes for SSH versions from the late 1990s in major ba=
ckbone routing gear, so we're talking a 15-year lifespan at least, which is=
 where the 5K days came from).

Oh, and given your affiliation, I was tempted to add: "So Microsoft are pla=
nning to roll out an update to Windows XP then?" :-).

Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From nobody Mon Oct 20 15:28:23 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68A41ACF77 for ; Mon, 20 Oct 2014 15:28:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-m8iQi45bCq for ; Mon, 20 Oct 2014 15:28:08 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::741]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A139F1ACF09 for ; Mon, 20 Oct 2014 15:28:08 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Mon, 20 Oct 2014 22:27:46 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Mon, 20 Oct 2014 22:27:46 +0000
From: Andrei Popov 
To: "Salz, Rich" , Hubert Kario 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: AQHP6g/vkqpMmvBKoUCxL3G2jHnzlpw0TqsAgABoBICAAAgfwIAACI2AgAAH2aCAACaKgIAAAF8ggAAHRICAAAleYK+wogZE0FPRwjCAAANGUIAAFwzw
Date: Mon, 20 Oct 2014 22:27:45 +0000
Message-ID: <5f6ad6fa2ae049fa8e1400eeda45043d@BL2PR03MB419.namprd03.prod.outlook.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>   <7fe248e5b4374fbd8d04ff460bc3ace8@BL2PR03MB419.namprd03.prod.outlook.com> <76533ab02b644597a170cb5b76a42a99@BY2PR03MB554.namprd03.prod.outlook.com>   <8f805ba832b645e680bb5aba5b878265@BL2PR03MB419.namprd03.prod.outlook.com> <2063553608.14767069.1413800030437.JavaMail.zimbra@redhat.com> <95e6d46442e24f7dbc6151e2cce9d14f@BL2PR03MB419.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4907@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4907@USMBX1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB419;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 03706074BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(199003)(189002)(13464003)(87936001)(54356999)(50986999)(76176999)(2656002)(19580405001)(85852003)(19580395003)(46102003)(86612001)(20776003)(64706001)(80022003)(21056001)(101416001)(230783001)(4396001)(108616004)(92566001)(85306004)(40100003)(122556002)(93886004)(31966008)(76576001)(105586002)(106116001)(76482002)(99396003)(106356001)(86362001)(97736003)(95666004)(33646002)(120916001)(74316001)(99286002)(107046002)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Xw0PRMIZ5sEpHVkGU3gH-FVgD5I
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 22:28:14 -0000

SGF2aW5nIGJvdGggU0NTViBhbmQgZXh0ZW5zaW9uIHdvdWxkIGluZGVlZCBiZSB3b3JzZSB0aGFu
IGp1c3QgaGF2aW5nIHRoZSBTQ1NWLiBJJ20gYWR2b2NhdGluZyBleHRlbnNpb24gYXMgYSBsZXNz
IGhhY2t5LCBtb3JlIGZvcndhcmQtbG9va2luZyBtZWNoYW5pc20gdGhhdCBhbHNvIHBvdGVudGlh
bGx5IGFsbG93cyBtb3JlIGZsZXhpYmlsaXR5IGluIHRoZSBmYWxsYmFjayBzZXF1ZW5jZS4NCg0K
Q2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNh
bHosIFJpY2ggW21haWx0bzpyc2FsekBha2FtYWkuY29tXSANClNlbnQ6IE1vbmRheSwgT2N0b2Jl
ciAyMCwgMjAxNCAyOjAyIFBNDQpUbzogQW5kcmVpIFBvcG92OyBIdWJlcnQgS2FyaW8NCkNjOiB0
bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbVExTXSBUaGUgVExTX0ZBTExCQUNLX1NDU1YgdGlt
ZSBib21iICh3YXM6IFJlOiBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi10
bHMtZG93bmdyYWRlLXNjc3YtMDApDQoNCj4gPjEuMyB0byAxLjIuIE92ZXIgMTAlIG9mIEludGVy
bmV0IHdlYiBzZXJ2ZXJzIGFyZSBpbnRvbGVyYW50IHRvIDEuMyANCj4gPkNsaWVudEhlbGxvDQoN
ClNocnVnLCBzaW5jZSBpdCdzIG5vdCBkZWZpbmVkIEkgZG9uJ3QgdGhpbmsgaXQgbWF0dGVycyB0
aGF0IG11Y2guDQoNCj4gMS4zIHRvIDEuMiBjb3VsZCBiZSBwcm90ZWN0ZWQgYnkgYW4gZXh0ZW5z
aW9uOyBJIHRoaW5rIFNDU1YgaXMgb25seSANCj4gbmVlZGVkIHRvIHByb3RlY3QgdGhlIGRvd25n
cmFkZSBmcm9tIFRMUzEuMCB0byBTU0wzLg0KDQpJIHdvdWxkIHJhdGhlciBub3QgaGF2ZSB0d28g
bWVjaGFuaXNtcyB0aGF0IGRvIHRoZSBleGFjdCBzYW1lIHRoaW5nLg0KDQotLQ0KUHJpbmNpcGFs
IFNlY3VyaXR5IEVuZ2luZWVyLCBBa2FtYWkgVGVjaG5vbG9naWVzDQpJTTogcnNhbHpAamFiYmVy
Lm1lIFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg==


From nobody Mon Oct 20 15:36:33 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0406F1ACF8F for ; Mon, 20 Oct 2014 15:36:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKCx9bIRVVY0 for ; Mon, 20 Oct 2014 15:36:30 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0144.outbound.protection.outlook.com [65.55.169.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC4A1ACF8C for ; Mon, 20 Oct 2014 15:36:29 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Mon, 20 Oct 2014 22:36:28 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Mon, 20 Oct 2014 22:36:28 +0000
From: Andrei Popov 
To: Yuhong Bao , "tls@ietf.org" 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: AQHP6g/vkqpMmvBKoUCxL3G2jHnzlpw0TqsAgABoBICAAAgfwIABAiWAgAB5PrWAA1xREA==
Date: Mon, 20 Oct 2014 22:36:28 +0000
Message-ID: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB418;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 03706074BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(189002)(199003)(377454003)(120916001)(85852003)(99396003)(40100003)(19580395003)(122556002)(19580405001)(92566001)(15975445006)(76482002)(108616004)(230783001)(21056001)(4396001)(20776003)(64706001)(86362001)(31966008)(87936001)(80022003)(46102003)(2656002)(33646002)(93886004)(85306004)(86612001)(76576001)(107886001)(107046002)(97736003)(74316001)(106356001)(106116001)(99286002)(95666004)(105586002)(101416001)(76176999)(50986999)(54356999)(2501002)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/swPaPRVz9r3-BoVwjV3pjA6bCHY
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 22:36:32 -0000

It would be nice to keep TLS extensions optional; unfortunately, TLS extens=
ions mechanism is already used to patch protocol security issues: renegotia=
tion info, extended master secret extensions come to mind. I think we've cr=
ossed this bridge a long time ago.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao
Sent: Saturday, October 18, 2014 12:03 PM
To: tls@ietf.org
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group =
Last Call for draft-ietf-tls-downgrade-scsv-00)

Bodo Moeller  acm.org> writes:
> Even once we no longer need to worry about extension *intolerant*=20
> servers,
we still should take into account that extension *support* remains optional=
 for TLS servers. Servers can legitimately ignore ClientServer.extensions e=
ntirely. Having a fallback_indication TLS extension would be overly onerous=
 for such servers: they'd need to implement extension parsing just to be ab=
le to find this one signal.=20
MS had to do this in order to backport the TLS renegotiation extension to X=
P/Server 2003 back in 2010.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From nobody Mon Oct 20 15:51:13 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144851ACF98 for ; Mon, 20 Oct 2014 15:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56Q1lxc7oKCS for ; Mon, 20 Oct 2014 15:51:10 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEAFA1ACF93 for ; Mon, 20 Oct 2014 15:51:09 -0700 (PDT)
Received: from mail-yh0-f52.google.com (mail-yh0-f52.google.com [209.85.213.52]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0LvNfb-1Y6zQe03Bj-010Zho; Tue, 21 Oct 2014 00:51:07 +0200
Received: by mail-yh0-f52.google.com with SMTP id f10so36175yha.25 for ; Mon, 20 Oct 2014 15:51:05 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.24.225 with SMTP id x61mr43514985yhx.39.1413845465865; Mon, 20 Oct 2014 15:51:05 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Mon, 20 Oct 2014 15:51:05 -0700 (PDT)
In-Reply-To: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>      
Date: Tue, 21 Oct 2014 00:51:05 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0112ce2ac2aa750505e28c7d
X-Provags-ID: V02:K0:TsgtQNkYTZ9cOgpl8oYHSZXPhP869isM0eQI/NpP6rA 0CGQ+mzmkyr6Vc0vHxG/TNjkE4zzzFv/GV06V2L45oFgErktzV hZ3VIP0GYeXbTR0CHh1cj6QLQR0p6J1ZnTx+/yBVFo6jvOtiTG JEfc2wdJ/ln5o3VVE3WkDDhJJuaAeBPAhpLX9QST5JaK70/HRb f4x30LcxOUp3xiJcFNXBk44NQFfWvriiy+RblA78cMSrtt3NGh jftQ6dfO3+2+Ypwv2W6VY3zOHyf6eCwBDg44WyNw76be+zT6wa 41NkA8r4iA0+jvwC61sBmOYa2pC0KviYzoeBxLIsVQcTZ0kYcj BOIKxdbqw4KZcmTYmYTQLkxWlYusapHGPApardmb/FmzZu0eWb 2IT+hGwDVH0I1Zz+rAmdIHYvHamtw/DxIk9hQBMx4Qp0Guwt+2 dO1b9
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5m6fxBdUX45I46Inlon6RJPGsEI
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 22:51:11 -0000

--089e0112ce2ac2aa750505e28c7d
Content-Type: text/plain; charset=UTF-8

Andrei Popov :

It would be nice to keep TLS extensions optional; unfortunately, TLS
> extensions mechanism is already used to patch protocol security issues:
> renegotiation info, extended master secret extensions come to mind. I think
> we've crossed this bridge a long time ago.


You should be able to get away without the actual renegotiation_info
extension if you don't support renegotiation.

Bodo

--089e0112ce2ac2aa750505e28c7d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Andr=
ei Popov <Andrei.Popov@microsoft.com>:

It would be nice to keep TLS exten=
sions optional; unfortunately, TLS extensions mechanism is already used to =
patch protocol security issues: renegotiation info, extended master secret =
extensions come to mind. I think we've crossed this bridge a long time =
ago.

You should be able to get away without=
 the actual renegotiation_info extension if you don't support renegotia=
tion.

Bodo



--089e0112ce2ac2aa750505e28c7d--


From nobody Mon Oct 20 16:28:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D10A1ACE1B for ; Mon, 20 Oct 2014 16:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxhsT5zQOoO4 for ; Mon, 20 Oct 2014 16:28:26 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:785]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEEDF1A88A6 for ; Mon, 20 Oct 2014 16:28:25 -0700 (PDT)
Received: from BY2PR03MB554.namprd03.prod.outlook.com (10.141.141.156) by BY2PR03MB554.namprd03.prod.outlook.com (10.141.141.156) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Mon, 20 Oct 2014 23:28:01 +0000
Received: from BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) by BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) with mapi id 15.00.1054.004; Mon, 20 Oct 2014 23:28:01 +0000
From: Marsh Ray 
To: Bodo Moeller , "tls@ietf.org" 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: AQHP6g/w1BhRgIoKW0S6M5mRt7fur5w0TqsAgABoBICAAAjbgIABAWmAgAB5PtGAA15CAIAABBWAgAAH56A=
Date: Mon, 20 Oct 2014 23:28:01 +0000
Message-ID: <53b46263e14c4148b779cb3e9c57d02c@BY2PR03MB554.namprd03.prod.outlook.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>       
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ee31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB554;
x-forefront-prvs: 03706074BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(199003)(189002)(50986999)(76176999)(54356999)(93886004)(85306004)(86362001)(86612001)(46102003)(80022003)(64706001)(20776003)(16236675004)(95666004)(33646002)(230783001)(99396003)(76576001)(107886001)(74316001)(107046002)(106356001)(105586002)(120916001)(92566001)(99286002)(106116001)(108616004)(76482002)(15202345003)(40100003)(122556002)(2656002)(85852003)(101416001)(97736003)(21056001)(19625215002)(87936001)(4396001)(19609705001)(31966008)(2501002)(19300405004)(15975445006)(19580405001)(19580395003)(24736002)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB554; H:BY2PR03MB554.namprd03.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_53b46263e14c4148b779cb3e9c57d02cBY2PR03MB554namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OSCPejM5u3biD6fa8QSpx3MFSyo
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 23:28:28 -0000

--_000_53b46263e14c4148b779cb3e9c57d02cBY2PR03MB554namprd03pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCb2Rv
IE1vZWxsZXINCj4gWW91IHNob3VsZCBiZSBhYmxlIHRvIGdldCBhd2F5IHdpdGhvdXQgdGhlIGFj
dHVhbCByZW5lZ290aWF0aW9uX2luZm8NCj4gZXh0ZW5zaW9uIGlmIHlvdSBkb24ndCBzdXBwb3J0
IHJlbmVnb3RpYXRpb24uDQoNClRoZSB0aGluZyB3aXRoIHRoZSByZW5lZ290aWF0aW9uIGF0dGFj
ayBpcyB0aGUgY2xpZW50IGRvZXNu4oCZdCBrbm93IGluIGFkdmFuY2UgdGhhdCB0aGUgc2VydmVy
IGlzIHJlbmVnb3RpYXRpbmcuDQoNCklmIGNsaWVudHMgZG9u4oCZdCBzZW5kIFJJLCB0aGUgc2Vy
dmVyIGNhbuKAmXQgcHJvdGVjdCB0aGVtIGZyb20gcmVuZWdvdGlhdGlvbiBhdHRhY2tzLg0KDQpJ
ZiBzZXJ2ZXJzIGRvbuKAmXQgcGFyc2UgYW5kIHJlc3BvbmQgd2l0aCByZW5lZ290aWF0aW9uIGlu
Zm8sIHRoZW4gY2xpZW50cyBjYW7igJl0IGtub3cgdGhhdCB0aGV5IGFyZSBzZWN1cmUgZnJvbSBy
ZW5lZ290aWF0aW9uIGF0dGFja3MuDQoNCldlIGV2ZW50dWFsbHkgbmVlZCB0byBnZXQgdG8gYSBk
YXkgd2hlcmUgY2xpZW50cyBhbmQgc2VydmVycyBjYW4gYWN0aXZlbHkgcmVmdXNlIHRvIHRhbGsg
dG9kYXnigJlzIFRMUyB2ZXJzaW9ucyB3aXRob3V0IFJJLiBZZWFoLCBpdCB3aWxsIHRha2UgYSBs
b25nIHRpbWUuDQoNCkJhc2ljYWxseSwgY2xpZW50cyBhbmQgc2VydmVycyBvcHRpbmcgb3V0IG9m
IFJJIHRvZGF5IGJlY2F1c2UgdGhleSBmZWVsIOKAnGl0IGRvZXNu4oCZdCBhZmZlY3QgbWXigJ0g
YXJlIHRvbW9ycm934oCZcyDigJxhdXRvIGRvd25ncmFkZSB0byBTU0x2MyBiZWNhdXNlIHdobyBu
ZWVkcyBUTFMgMS4w4oCdLg0KDQoNCi0gICAgICAgICAgTWFyc2gNCg0KDQo=

--_000_53b46263e14c4148b779cb3e9c57d02cBY2PR03MB554namprd03pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N
c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw
aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp
Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv
cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3
aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm
aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQxMzQ3OTI0MTsNCgltc28tbGlz
dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0NDkzNjU0NDggOTIxNjk5
OTc0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5
IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt
Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh
bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs
NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K
QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX
aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm
b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu
b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJn
aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i
PkJvZG8gTW9lbGxlcjxicj4NCjwvc3Bhbj4mZ3Q7IFlvdSBzaG91bGQgYmUgYWJsZSB0byBnZXQg
YXdheSB3aXRob3V0IHRoZSBhY3R1YWwgcmVuZWdvdGlhdGlvbl9pbmZvPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IGV4dGVuc2lvbiBpZiB5b3UgZG9uJ3Qgc3VwcG9y
dCByZW5lZ290aWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5UaGUgdGhpbmcgd2l0aCB0aGUgcmVuZWdvdGlhdGlvbiBhdHRh
Y2sgaXMgdGhlIGNsaWVudCBkb2VzbuKAmXQga25vdyBpbiBhZHZhbmNlIHRoYXQgdGhlIHNlcnZl
ciBpcyByZW5lZ290aWF0aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgY2xpZW50cyBkb27igJl0IHNlbmQgUkks
IHRoZSBzZXJ2ZXIgY2Fu4oCZdCBwcm90ZWN0IHRoZW0gZnJvbSByZW5lZ290aWF0aW9uIGF0dGFj
a3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5JZiBzZXJ2ZXJzIGRvbuKAmXQgcGFyc2UgYW5kIHJlc3BvbmQgd2l0aCBy
ZW5lZ290aWF0aW9uIGluZm8sIHRoZW4gY2xpZW50cyBjYW7igJl0IGtub3cgdGhhdCB0aGV5IGFy
ZSBzZWN1cmUgZnJvbSByZW5lZ290aWF0aW9uIGF0dGFja3MuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBldmVudHVh
bGx5IG5lZWQgdG8gZ2V0IHRvIGEgZGF5IHdoZXJlIGNsaWVudHMgYW5kIHNlcnZlcnMgY2FuIGFj
dGl2ZWx5IHJlZnVzZSB0byB0YWxrIHRvZGF54oCZcyBUTFMgdmVyc2lvbnMgd2l0aG91dCBSSS4g
WWVhaCwgaXQgd2lsbCB0YWtlIGEgbG9uZyB0aW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmFzaWNhbGx5LCBjbGll
bnRzIGFuZCBzZXJ2ZXJzIG9wdGluZyBvdXQgb2YgUkkgdG9kYXkgYmVjYXVzZSB0aGV5IGZlZWwg
4oCcaXQgZG9lc27igJl0IGFmZmVjdCBtZeKAnSBhcmUgdG9tb3Jyb3figJlzIOKAnGF1dG8gZG93
bmdyYWRlIHRvIFNTTHYzIGJlY2F1c2Ugd2hvIG5lZWRzIFRMUw0KIDEuMOKAnS48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6
bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNw
YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48
L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+TWFyc2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_53b46263e14c4148b779cb3e9c57d02cBY2PR03MB554namprd03pro_--


From nobody Mon Oct 20 16:34:55 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AF21ACC84 for ; Mon, 20 Oct 2014 16:34:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYh6_BVM-4n4 for ; Mon, 20 Oct 2014 16:34:51 -0700 (PDT)
Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E0061A0673 for ; Mon, 20 Oct 2014 16:34:51 -0700 (PDT)
Received: by mail-ob0-f178.google.com with SMTP id wn1so64626obc.23 for ; Mon, 20 Oct 2014 16:34:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Nv1E8chEsB9kt1i48FIYHG+E9qdn9qJ6xWE3BOc5pQM=; b=ZSJm+OedLvXV8ndk7HqbQokWnjSagehIcoZfUoNbhTpCQ5eCz2hd63K8ULuPReR827 q5VeyHOJJFbtlmvVGcVwtts+aRcscgb55Uv6Quk9dEaUANy8h2gcb+GgbsgpxXqGxu/t V5IiSRO9le0p7OOKzMKoWE02ZBAk3SDnebtvrFS/WUhSqyY5B/BK3ZvrM1KIni8DsXuO c5Zm87eQbpvhHLiRQIXYakCGRatZbdjW3phYfVBpd2YnC/iBOHR8mq4zjoW0ARj7Z6gk lUoPy095J/QslM6+MkaNVC0LepLolPIhRnrUm9e3QTFAoO5wEhiCPWZ9fx/zD0q7wYdc mPfQ==
X-Gm-Message-State: ALoCoQlvhiM+NJzNVU3nljxvDSVXRqkxpNyvqdTboohhFTHeOUa+nq5KVVHRD15X5DRdpoyU5ais
MIME-Version: 1.0
X-Received: by 10.202.80.147 with SMTP id e141mr83856oib.80.1413848090527; Mon, 20 Oct 2014 16:34:50 -0700 (PDT)
Received: by 10.76.93.9 with HTTP; Mon, 20 Oct 2014 16:34:50 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>
Date: Mon, 20 Oct 2014 16:34:50 -0700
Message-ID: 
From: Brian Smith 
To: "Salz, Rich" 
Content-Type: multipart/alternative; boundary=001a113d801833ded90505e329e1
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/el0t3t40EYh_7HXLP2A_M-PnP7s
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 23:34:53 -0000

--001a113d801833ded90505e329e1
Content-Type: text/plain; charset=UTF-8

Rich,

I think your suggestion is a very good idea. In particular, note that
session tickets could be encrypted during the handshake, but
ServerHello.session_id
cannot. This is valuable because it allows for a level of unlinkability
between the initial connection for a session and a resumption of that
session. If the server rotates tickets for a session on every connection
(resumption or otherwise), this unlinkability would be maintained against
all connections for a session. This seems like a valuable privacy feature.

On Mon, Oct 20, 2014 at 1:11 PM, Salz, Rich  wrote:

> For 1.3 we bring in the extension definitions from 5077. For the wire
> format, it doesn't matter if the information is a session identifier (a
> short string, referring to state maintained on the server) or a ticket (the
> actual crypto state, stored on the client). Perhaps to be general, we call
> it session token.
>

I suggest, to minimize changes from RFC 5077, and to minimize confusion,
that we continue to call it a session ticket.

A TLS 1.3 client MUST send an empty session_id field. It may send a ticket
> extension. If the server is willing to accept the crypto state, it sends a
> "1" in the returned session_id field, otherwise it sends an empty
> session_id. This is the only use of session_id in TLS 1.3.
>

This change from RFC5077 is not necessary. You just make this change
instead:

-  If a server is planning on issuing a session ticket to a client that
-  does not present one, it SHOULD include an empty Session ID in the
-  ServerHello.  If the server rejects the ticket and falls back to the
-  full handshake then it may include a non-empty Session ID to indicate
-  its support for stateful session resumption.  If the client receives
-  a session ticket from the server, then it discards any Session ID
-  that was sent in the ServerHello.

-

-  When presenting a ticket, the client MAY generate and include a
-  Session ID in the TLS ClientHello.  If the server accepts the ticket
-  and the Session ID is not empty, then it MUST respond with the same
-  Session ID present in the ClientHello.  This allows the client to
-  easily differentiate when the server is resuming a session from when
-  it is falling back to a full handshake.  Since the client generates a
-  Session ID, the server MUST NOT rely upon the Session ID having a
-  particular value when validating the ticket.  If a ticket is
-  presented by the client, the server MUST NOT attempt to use the
-  Session ID in the ClientHello for stateful session resumption.

-  Alternatively, the client MAY include an empty Session ID in the

-  ClientHello.  In this case, the client ignores the Session ID sent in

-  the ServerHello and determines if the server is resuming a session by

+  The client MUST always include an empty Session ID in the ClientHello.

+  The server MUST always include an empty Session ID in the ServerHello.

+  The client determines if the server is resuming a session by

the subsequent handshake messages.


This is a smaller change for implementations and leaks less
information in the plaintext part of the handshake. In particular, on
top of this change, you could in theory make it so that the full
handshake and the resumption handshake look the same on the wire
(modulo leaking the distinction via timing). As I said before [2], I
think that is worth trying to accomplish, both for maximizing interop
as well as improving privacy.


Cheers,

Brian

[1] https://tools.ietf.org/html/rfc5077#section-3.4
[2] http://www.ietf.org/mail-archive/web/tls/current/msg10903.html

--001a113d801833ded90505e329e1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Rich=
,

I th=
ink your suggestion is a very good idea. In particular, note that session t=
ickets could be encrypted during the handshake, but ServerHello.session_id cannot. This is valuable bec=
ause it allows for a level of unlinkability between the initial connection =
for a session and a resumption of that session. If the server rotates ticke=
ts for a session on every connection (resumption or otherwise), this unlink=
ability would be maintained against all connections for a session. This see=
ms like a valuable privacy feature.
=

On Mon, Oct 20, 2014 at 1:11 PM, Salz,=
 Rich <rsalz@akamai.com> wrote:
For 1.3 w=
e bring in the extension definitions from 5077. For the wire format, it doe=
sn't matter if the information is a session identifier (a short string,=
 referring to state maintained on the server) or a ticket (the actual crypt=
o state, stored on the client). Perhaps to be general, we call it session t=
oken.

I suggest, to minimize changes fr=
om RFC 5077, and to minimize confusion, that we continue to call it a sessi=
on ticket.

A TLS 1.3 client MUST send =
an empty session_id field. It may send a ticket extension. If the server is=
 willing to accept the crypto state, it sends a "1" in the return=
ed session_id field, otherwise it sends an empty session_id. This is the on=
ly use of session_id in TLS 1.3.

This c=
hange from RFC5077 is not necessary. You just make this change instead:

-  If a server is planning on issuing =
a session ticket to a client that
-  does not present one, it SHOULD include an empty Session ID in the
-  ServerHello.  If the server rejects the ticket and falls back to the
-  full handshake then it may include a non-empty Session ID to indicate
-  its support for stateful session resumption.  If the client receives
-  a session ticket from the server, then it discards any Session ID
-  that was sent in the ServerHello.
-
=

-  When presenting a ticket, the client MAY generate and inc=
lude a
-  Session ID in the TLS ClientHello.  If the server accepts the ticket
-  and the Session ID is not empty, then it MUST respond with the same
-  Session ID present in the ClientHello.  This allows the client to
-  easily differentiate when the server is resuming a session from when
-  it is falling back to a full handshake.  Since the client generates a
-  Session ID, the server MUST NOT rely upon the Session ID having a
-  particular value when validating the ticket.  If a ticket is
-  presented by the client, the server MUST NOT attempt to use the
-  Session ID in the ClientHello for stateful session resumption.
-  Alternatively, the client MAY include an empty Session ID in th=
e
-  ClientHello.  In this case, the client ignores the Session ID sent =
in
-  the ServerHello and determines if the server is resuming a session b=
y
+  The client MUST always include an empty Session ID in the ClientHel=
lo.
+  The server MUST always include an empty Session ID in the ServerH=
ello.
+  The client determines if the server is resuming a session by   the subsequent handshake messages.

This is a smaller=C2=A0change for implementations =
and leaks less information in the plaintext part of the handshake. In parti=
cular, on top of this change, you could in theory make it so that the full =
handshake and the resumption handshake look the same on the wire (modulo le=
aking the distinction via timing). As I said before [2], I think that is wo=
rth trying to accomplish, both for maximizing interop as well as improving =
privacy.

Cheers,
<=
/pre>
Brian



--001a113d801833ded90505e329e1--


From nobody Mon Oct 20 16:48:31 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5071ACF61 for ; Mon, 20 Oct 2014 16:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cp6GfDRdDE6x for ; Mon, 20 Oct 2014 16:48:23 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320E81ACF60 for ; Mon, 20 Oct 2014 16:48:23 -0700 (PDT)
Received: from mail-yh0-f52.google.com (mail-yh0-f52.google.com [209.85.213.52]) by mrelayeu.kundenserver.de (node=mreue001) with ESMTP (Nemesis) id 0MVV8g-1XdgaY24Z4-00Yjnt; Tue, 21 Oct 2014 01:48:20 +0200
Received: by mail-yh0-f52.google.com with SMTP id f10so162876yha.11 for ; Mon, 20 Oct 2014 16:48:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.50.196 with SMTP id z44mr45113418yhb.18.1413848899392; Mon, 20 Oct 2014 16:48:19 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Mon, 20 Oct 2014 16:48:19 -0700 (PDT)
In-Reply-To: <53b46263e14c4148b779cb3e9c57d02c@BY2PR03MB554.namprd03.prod.outlook.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>        <53b46263e14c4148b779cb3e9c57d02c@BY2PR03MB554.namprd03.prod.outlook.com>
Date: Tue, 21 Oct 2014 01:48:19 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e01634d986a1ce90505e35934
X-Provags-ID: V02:K0:CZdUppmdbCH9B4DVBy8nrfCBHrpRJBuCLtS7pQp/6y3 Da9DBbWWJ6LHLtF9cRvzOgMHpeD/P++H+EosDVJrnF2djGjq6g 4bpeFdEiSKjuK/hNdzQk0JxWoTYS6oGza+glsfIgaE7QPZ7mCt R4OwZDLAOZY8eagMRLLy0FOB4j/JJU5XLux8iJUB27ifMTecO+ MHodalZHaRtAuQb5nSyv4y8IVDY3GJWui4RGCQS81Om3QrknFG z2KOSf4cMKdQyNNCv91BVTtEh8FYkSpmmF92qxE7StZgkwtgK3 yhNvX2KTPFqS1BbXVgBOjmSKMH85G689uC/h6altNT5iv8OAl9 ESlLwwi6vb+/zcZ7YHu6d2izZ9LWZ5zIIgsN48e+jlZSM1NJXl 0QOMmhtMTfjZJTRMUy3y/1HKJW5EaESxMjNeS57vWzAROURHqZ l4r2V
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pGDWRjHvvVeh6RezPXzaSU_Rg2I
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 23:48:24 -0000

--089e01634d986a1ce90505e35934
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Marsh Ray :


> > You should be able to get away without the actual renegotiation_info
>
> > extension if you don't support renegotiation.
>


> The thing with the renegotiation attack is the client doesn=E2=80=99t kno=
w in
> advance that the server is renegotiating.
>
>
>
> If clients don=E2=80=99t send RI, the server can=E2=80=99t protect them f=
rom renegotiation
> attacks.
>

I know. What I meant is that expecting TLS_EMPTY_RENEGOTIATION_INFO_SCSV
would be sufficient if you don't do renegotiation. (The server still needs
to respond with an empty extension, but that's just a fixed string.)

Bodo

--089e01634d986a1ce90505e35934
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Mars=
h Ray <maray@microsoft.com>:
=C2=A0

> You should be able to get away without the act=
ual renegotiation_info


> extension if you don't support renegotiatio=
n.
=C2=A0


The thing with the renegotiation atta=
ck is the client doesn=E2=80=99t know in advance that the server is renegot=
iating.


=C2=A0


If clients don=E2=80=99t send RI, the server=
 can=E2=80=99t protect them from renegotiation attacks.

I know. What I meant is that expecting =
TLS_EMPTY_RENEGOTIATION_INFO_SCSV would be sufficient if you don't do r=
enegotiation. (The server still needs to respond with an empty extension, b=
ut that's just a fixed string.)

Bodo



--089e01634d986a1ce90505e35934--


From nobody Mon Oct 20 16:58:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499351ACF82 for ; Mon, 20 Oct 2014 16:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3joxSIEViwxN for ; Mon, 20 Oct 2014 16:58:35 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4871F1ACF7F for ; Mon, 20 Oct 2014 16:58:35 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 448CB2AB2B5; Mon, 20 Oct 2014 23:58:33 +0000 (UTC)
Date: Mon, 20 Oct 2014 23:58:33 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141020235832.GK19158@mournblade.imrryr.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54458113.1050304@polarssl.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G6HXLj0zwygkWiZI2a7MrIKpo64
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 23:58:36 -0000

On Mon, Oct 20, 2014 at 11:39:31PM +0200, Manuel P?gouri?-Gonnard wrote:

> > The RFC should clarify that the negotiated cipher **MUST** be honored 
> > when encrypting the state that will be sent to the client. [1]

I am having trouble parsing the original suggestion above.

> While I'm sympathetic with the goal, I'm afraid that will complicate
> implementations more than necessary. How about requiring to use a key length at
> least a high as the highest supported ciphersuite instead?

Does it mean (as I think you're saying) that session tickets MUST
be encrypted with the session's negotiated ciphersuite?  That seems
rather unmanageable.  A single sufficiently strong key is likely
far more realistic.

With keys for clusters of servers rotated by code external to the
TLS library, asking for a key for every algorith/size is impractical.

-- 
	Viktor.


From nobody Mon Oct 20 17:10:52 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E36C1ACF88 for ; Mon, 20 Oct 2014 17:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouVw90e06Eka for ; Mon, 20 Oct 2014 17:10:47 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB53E1ACFB0 for ; Mon, 20 Oct 2014 17:09:22 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 21 Oct 2014 00:09:00 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Tue, 21 Oct 2014 00:09:00 +0000
From: Andrei Popov 
To: Bodo Moeller , "tls@ietf.org" 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: AQHP6g/vkqpMmvBKoUCxL3G2jHnzlpw0TqsAgABoBICAAAgfwIABAiWAgAB5PrWAA1xREIAABgaAgAAVbdA=
Date: Tue, 21 Oct 2014 00:09:00 +0000
Message-ID: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com>	<543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>       
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB420;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0371762FE7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(377454003)(199003)(31966008)(20776003)(105586002)(106116001)(106356001)(4396001)(95666004)(99286002)(107886001)(15202345003)(107046002)(74316001)(19300405004)(33646002)(16236675004)(87936001)(230783001)(40100003)(122556002)(108616004)(76176999)(93886004)(85306004)(54356999)(15975445006)(85852003)(2656002)(19580405001)(19580395003)(50986999)(19609705001)(21056001)(92566001)(76576001)(46102003)(76482002)(19625215002)(2501002)(86362001)(80022003)(99396003)(120916001)(101416001)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_ad51b80ad13342f4989448f21ede2538BL2PR03MB419namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tRS-SmTc6wf6IZm-L4lqn58elfk
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 00:10:49 -0000

--_000_ad51b80ad13342f4989448f21ede2538BL2PR03MB419namprd03pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

WWVzLCBhbmQgeW91IHNob3VsZCBiZSBhYmxlIHRvIGdldCBhd2F5IHdpdGhvdXQgRG93bmdyYWRl
LVNDU1YgaWYgeW91IGRvIG5vdCBkbyBmYWxsYmFja3MgKHdoaWNoIGFyZSBub3QgZXZlbiBwYXJ0
IG9mIHRoZSBUTFMgcHJvdG9jb2wpLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBCb2Rv
IE1vZWxsZXIgW21haWx0bzpibW9lbGxlckBhY20ub3JnXQ0KU2VudDogTW9uZGF5LCBPY3RvYmVy
IDIwLCAyMDE0IDM6NTEgUE0NClRvOiB0bHNAaWV0Zi5vcmcNCkNjOiBBbmRyZWkgUG9wb3YNClN1
YmplY3Q6IFJlOiBbVExTXSBUaGUgVExTX0ZBTExCQUNLX1NDU1YgdGltZSBib21iICh3YXM6IFJl
OiBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi10bHMtZG93bmdyYWRlLXNj
c3YtMDApDQoNCkFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRv
OkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj46DQoNCkl0IHdvdWxkIGJlIG5pY2UgdG8ga2Vl
cCBUTFMgZXh0ZW5zaW9ucyBvcHRpb25hbDsgdW5mb3J0dW5hdGVseSwgVExTIGV4dGVuc2lvbnMg
bWVjaGFuaXNtIGlzIGFscmVhZHkgdXNlZCB0byBwYXRjaCBwcm90b2NvbCBzZWN1cml0eSBpc3N1
ZXM6IHJlbmVnb3RpYXRpb24gaW5mbywgZXh0ZW5kZWQgbWFzdGVyIHNlY3JldCBleHRlbnNpb25z
IGNvbWUgdG8gbWluZC4gSSB0aGluayB3ZSd2ZSBjcm9zc2VkIHRoaXMgYnJpZGdlIGEgbG9uZyB0
aW1lIGFnby4NCg0KWW91IHNob3VsZCBiZSBhYmxlIHRvIGdldCBhd2F5IHdpdGhvdXQgdGhlIGFj
dHVhbCByZW5lZ290aWF0aW9uX2luZm8gZXh0ZW5zaW9uIGlmIHlvdSBkb24ndCBzdXBwb3J0IHJl
bmVnb3RpYXRpb24uDQoNCkJvZG8NCg0K

--_000_ad51b80ad13342f4989448f21ede2538BL2PR03MB419namprd03pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46
MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT
ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk
ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K
PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+
PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp
bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgYW5k
IHlvdSBzaG91bGQgYmUgYWJsZSB0byBnZXQgYXdheSB3aXRob3V0IERvd25ncmFkZS1TQ1NWIGlm
IHlvdSBkbyBub3QgZG8gZmFsbGJhY2tzICh3aGljaCBhcmUgbm90IGV2ZW4gcGFydCBvZiB0aGUg
VExTIHByb3RvY29sKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZHJlaTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z
cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBCb2RvIE1vZWxsZXIgW21haWx0
bzpibW9lbGxlckBhY20ub3JnXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAy
MCwgMjAxNCAzOjUxIFBNPGJyPg0KPGI+VG86PC9iPiB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8
L2I+IEFuZHJlaSBQb3Bvdjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gVGhlIFRMU19G
QUxMQkFDS19TQ1NWIHRpbWUgYm9tYiAod2FzOiBSZTogV29ya2luZyBHcm91cCBMYXN0IENhbGwg
Zm9yIGRyYWZ0LWlldGYtdGxzLWRvd25ncmFkZS1zY3N2LTAwKTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kcmVpIFBvcG92ICZsdDs8YSBocmVm
PSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRy
ZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2tx
dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw
YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow
aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd291bGQgYmUgbmljZSB0byBrZWVwIFRMUyBl
eHRlbnNpb25zIG9wdGlvbmFsOyB1bmZvcnR1bmF0ZWx5LCBUTFMgZXh0ZW5zaW9ucyBtZWNoYW5p
c20gaXMgYWxyZWFkeSB1c2VkIHRvIHBhdGNoIHByb3RvY29sIHNlY3VyaXR5IGlzc3VlczogcmVu
ZWdvdGlhdGlvbiBpbmZvLCBleHRlbmRlZCBtYXN0ZXIgc2VjcmV0IGV4dGVuc2lvbnMgY29tZSB0
byBtaW5kLiBJIHRoaW5rIHdlJ3ZlIGNyb3NzZWQgdGhpcw0KIGJyaWRnZSBhIGxvbmcgdGltZSBh
Z28uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5Zb3Ugc2hvdWxkIGJlIGFibGUgdG8gZ2V0IGF3YXkgd2l0aG91dCB0aGUgYWN0dWFs
IHJlbmVnb3RpYXRpb25faW5mbyBleHRlbnNpb24gaWYgeW91IGRvbid0IHN1cHBvcnQgcmVuZWdv
dGlhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Qm9kbzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_ad51b80ad13342f4989448f21ede2538BL2PR03MB419namprd03pro_--


From nobody Mon Oct 20 17:40:56 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881251A1A62 for ; Mon, 20 Oct 2014 17:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWxlQvZMXxNB for ; Mon, 20 Oct 2014 17:40:47 -0700 (PDT)
Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9081ACF69 for ; Mon, 20 Oct 2014 17:40:47 -0700 (PDT)
Received: by mail-ob0-f180.google.com with SMTP id va2so139657obc.11 for ; Mon, 20 Oct 2014 17:40:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=9Zq1zU9jcxmgycoxAY/xeu/wUs/36vaaIr6Xuxbmm3U=; b=VgPnIgwU2/t9kTcbq7qDqogJZrZzAy9Wt9NMxiuCH04kcoiMkQiE43WENheV2X223g CVBhk/ixpiumasSQm7jIHMiozO2fP020FWVuGLrW8wKVamPwbz2CDyUFd5RCtTfxiEuj zRiBIqNzB87fZ9WQuXatcxjk5eg/qtHlHzNznCVzpuC5HtVfP34dsAMc1i5b8PuAWCWK wz66/VdcwTK/gWmYjqXdjARFZPodLJ5O5g5oxZJ0+gxfMwEwy9W3SQ9BLSR4Cmu9Zwtf S89+ETm1zQky70aHfkASIuO8owIcaaasT7Mh8kJkkq5uQpofF7a5OZGNYBMp5a43Nb0C 7pgw==
X-Gm-Message-State: ALoCoQmP4e7HMs9ZFLfIlC/3wlNZxtco8HCjRBj4bQZdNiZyZfySH6CYtmp4FFlPvQJHhIIhrd8h
MIME-Version: 1.0
X-Received: by 10.202.225.212 with SMTP id y203mr24787170oig.16.1413852046967;  Mon, 20 Oct 2014 17:40:46 -0700 (PDT)
Received: by 10.76.93.9 with HTTP; Mon, 20 Oct 2014 17:40:46 -0700 (PDT)
Date: Mon, 20 Oct 2014 17:40:46 -0700
Message-ID: 
From: Brian Smith 
To: Bodo Moeller 
Content-Type: multipart/alternative; boundary=001a113d2dfe0659760505e4157c
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H1llV_h0mipMQ0zOywZECed0Q5c
Cc: "tls@ietf.org" 
Subject: [TLS] POODLE applicability to TLS 1.0+ (was Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 00:40:53 -0000

--001a113d2dfe0659760505e4157c
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 17, 2014 at 2:56 AM, Bodo Moeller  wrote:

> Brian Smith :
>
>> If version downgrades during False Start are to be tolerated, then at
>>
> a minimum the security considerations of this draft must point out
>> that the mechanism is simple to subvert (partially, at least) when
>> False Start is used.
>>
>
> Exactly, but the detailed recommendations should go into an updated False
> Start I-D instead; I can do that.  Specifically, that spec could say that
> if the client sends TLS_FALLBACK_SCSV in the client hello, False Start
> SHOULD be disabled for that handshake. And then we'll also have to say that
> the client similarly should not use False Start with any protocol version
> for which it would send TLS_FALLBACK_SCSV in fallback retries (since
> otherwise the former recommendation wouldn't achieve anything.)  The
> TLS_FALLBACK_SCSV spec's Security Considerations, then, will include a
> reminder that allowing False Start with older protocol versions can be
> problematic, and that this is a (general) problem that TLS_FALLBACK_SCSV
> can't address.
>

I agree with you. However, please consider changing some of these SHOULDs
to MUSTs. As it is, every implementation already trivially conforms to the
current drafts, because all client implementations implement all the MUSTs
(the only MUST is that they MUST NOT send the TLS_FALLBACK_SCSV when
ClientHello.client_version is the highest version they support). That isn't
helpful.

Note that POODLE, or variants thereof, may apply also to TLS 1.0+
implementations. For example, back in 2010, I fixed a bug in NSS where NSS
did not verify all the padding bytes in TLS 1.0 records [1]. Thus, any
server that is using a version of NSS released prior to June 2010 is likely
vulnerable to POODLE-like attacks even if SSL 3.0 is completely disabled.
Further, note that the TLS 1.0 specification [2] does NOT say that
implementations must check the padding; that requirement was only added in
TLS 1.1 and TLS 1.2. Thus, an implementation could completely conform to
TLS 1.0 but still vulnerable to POODLE. Finally, even though the TLS 1.1
and TLS 1.2 specifications do say that implementations must check the
padding, it isn't necessarily the case that otherwise-working
implementations actually conform to that requirement, and there's no way
for the client to check that in a reliable, high-performance, and accurate
way.

Consequently, I think that:

1. Browsers must abandon the non-secure version rollback to versions prior
to TLS 1.2 completely.

2. The downgrade-scsv draft should be changed to say that implementations
MUST always send the TLS_FALLBACK_SCSV when ClientHello.client_version
indicates TLS 1.1 or lower if the client supports TLS 1.2.

So, I believe that your suggestion for client behavior is absolutely spot
> on. My point is just that the very same issue w.r.t. False Start and
> version downgrades exists if the client doesn't do any fallback retries --
> and those who implement such clients shouldn't have to read the
> TLS_FALLBACK_SCSV spec to find out when to allow False Start: this belongs
> into the False Start spec.
>

I agree that the False Start RFC should be updated to include this and
other considerations.


> Again, to be clear, I am not saving the downgrade SCSV is bad. I'm
>>
> saying it is surprising that the downgrade SCSV doesn't prevent
>> version downgrades, and that should be fixed.
>
>
> Right. I'll mention that potential surprise with False Start in
> TLS_FALLBACK_SCSV Security Considerations, and specify how to avoid it in
> the False Start specification.
>

Cheers,
Brian

--001a113d2dfe0659760505e4157c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Oct 17, 2014 at 2:56 AM, Bodo Moeller <bmoeller@acm.org> =
wrote:
Brian Smith <brian@briansmith.org>=
:
If version downgrades during False S=
tart are to be tolerated, then at

a minimum the security considerations of this draft must point out

that the mechanism is simple to subvert (partially, at least) when

False Start is used.

Exactly, bu=
t the detailed recommendations should go into an updated False Start I-D in=
stead; I can do that.=C2=A0 Specifically, that spec could say that if the c=
lient sends TLS_FALLBACK_SCSV in the client hello, False Start SHOULD be di=
sabled for that handshake. And then we'll also have to say that the cli=
ent similarly should not use False Start with any protocol version for whic=
h it would send TLS_FALLBACK_SCSV in fallback retries (since otherwise the =
former recommendation wouldn't achieve anything.) =C2=A0The TLS_FALLBAC=
K_SCSV spec's Security Considerations, then, will include a reminder th=
at allowing False Start with older protocol versions can be problematic, an=
d that this is a (general) problem that TLS_FALLBACK_SCSV can't address=
.

I agree with you.=
 However, please consider changing some of these SHOULDs to MUSTs. As it is=
, every implementation already trivially conforms to the current drafts, be=
cause all client implementations implement all the MUSTs (the only MUST is =
that they MUST NOT send the TLS_FALLBACK_SCSV when ClientHello.client_versi=
on is the highest version they support). That isn't helpful.
=

Note that POODLE, or variants thereof, may apply also to TLS=
 1.0+ implementations. For example, back in 2010, I fixed a bug in NSS wher=
e NSS did not verify all the padding bytes in TLS 1.0 records [1]. Thus, an=
y server that is using a version of NSS released prior to June 2010 is like=
ly vulnerable to POODLE-like attacks even if SSL 3.0 is completely disabled=
. Further, note that the TLS 1.0 specification [2] does NOT say that implem=
entations must check the padding; that requirement was only added in TLS 1.=
1 and TLS 1.2. Thus, an implementation could completely conform to TLS 1.0 =
but still vulnerable to POODLE. Finally, even though the TLS 1.1 and TLS 1.=
2 specifications do say that implementations must check the padding, it isn=
't necessarily the case that otherwise-working implementations actually=
 conform to that requirement, and there's no way for the client to chec=
k that in a reliable, high-performance, and accurate way.

Consequently, I think that:

1. Browsers mu=
st abandon the non-secure version rollback to versions prior to TLS 1.2 com=
pletely.

2. The downgrade-scsv draft should be cha=
nged to say that implementations MUST always send the TLS_FALLBACK_SCSV whe=
n ClientHello.client_version indicates TLS 1.1 or lower if the client suppo=
rts TLS 1.2.

So, I believe that your =
suggestion for client behavior is absolutely spot on. My point is just that=
 the very same issue w.r.t. False Start and version downgrades exists if th=
e client doesn't do any fallback retries -- and those who implement suc=
h clients shouldn't have to read the TLS_FALLBACK_SCSV spec to find out=
 when to allow False Start: this belongs into the False Start spec.

I agree that the False=
 Start RFC should be updated to include this and other considerations.
=C2=A0
Again, to be clear, I am not saving the downgrade SCSV is bad. I'm
=


saying it is surprising that the downgrade SCSV doesn't prevent

version downgrades, and that should be fixed.

Right. I'll mention that potential surprise with False Start =
in TLS_FALLBACK_SCSV Security Considerations, and specify how to avoid it i=
n the False Start specification.
<=
br>
Cheers,
Brian=C2=A0



--001a113d2dfe0659760505e4157c--


From nobody Mon Oct 20 17:52:16 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4006B1ACF65 for ; Mon, 20 Oct 2014 17:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHBVU_Hv5gM1 for ; Mon, 20 Oct 2014 17:52:12 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164701ACF0A for ; Mon, 20 Oct 2014 17:52:12 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 21 Oct 2014 00:52:10 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Tue, 21 Oct 2014 00:52:10 +0000
From: Andrei Popov 
To: Joseph Salowey , Chris Newman 
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: AQHP3c1Ub4FUPtdXakGIHJMHMTXmG5wx5z5wgARg/gCAA4jTEA==
Date: Tue, 21 Oct 2014 00:52:10 +0000
Message-ID: 
References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> <20141004033546.GG13254@mournblade.imrryr.org> <20141002175446.6EB7B1AEA6@ld9781.wdf.sap.corp> <54B025040D4F68B1E49919B8@nifty-silver.us.oracle.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB419;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0371762FE7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(55674003)(199003)(377454003)(164054003)(189002)(24454002)(76576001)(105586002)(31966008)(33646002)(95666004)(120916001)(74316001)(99286002)(107046002)(19617315012)(99396003)(106116001)(76482002)(15975445006)(86362001)(106356001)(19300405004)(19609705001)(85852003)(19580395003)(19580405001)(54356999)(50986999)(76176999)(87936001)(2656002)(92566001)(85306004)(108616004)(4396001)(230783001)(40100003)(122556002)(19625215002)(93886004)(16236675004)(46102003)(15202345003)(101416001)(80022003)(21056001)(20776003)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_cce9c5f96fe944d5b4f6007d1c4a1bb2BL2PR03MB419namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1PIFVBpd_sVwqv5G1q1Tzy9cmA8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 00:52:15 -0000

--_000_cce9c5f96fe944d5b4f6007d1c4a1bb2BL2PR03MB419namprd03pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIGludGVudCBvZiBkcmFmdC1pZXRmLXRscy1wcm9oaWJpdGluZy1yYzQgaXMgZXhhY3RseSB3
aGF0IHRoZSB0aXRsZSBzYXlzOiB0byBwcm9oaWJpdCB0aGUgdXNlIG9mIFJDNC1iYXNlZCBjaXBo
ZXIgc3VpdGVzIGluIHRoZSBUTFMgcHJvdG9jb2wuIEluIHByYWN0aWNlLCBwcm9oaWJpdGluZyBS
QzQgbWVhbnMgdGhhdCB0aGUgVExTIGNsaWVudHMgTVVTVCBOT1QgYWR2ZXJ0aXNlIFJDNCBzdXBw
b3J0LCBhbmQgdGhlIFRMUyBzZXJ2ZXJzIE1VU1QgTk9UIHNlbGVjdCBhbiBSQzQgY2lwaGVyIHN1
aXRlLiBCb3RoIHBhcnRzIGFyZSBjcnVjaWFsbHkgaW1wb3J0YW50IHRvIGFjaGlldmUgdGhlIHB1
cnBvc2Ugb2YgdGhlIEktRC4NCg0KSWYgdGhlIFRMUyBXRyBjYW5ub3QgcmVhY2ggcm91Z2ggY29u
c2Vuc3VzIHRoYXQgUkM0IGNpcGhlciBzdWl0ZXMgbmVlZCB0byBiZSBwcm9oaWJpdGVkLCB0aGVu
IEkgdGhpbmsgdGhlIHdheSBmb3J3YXJkIGlzIGZvciB0aGUgV0cgdG8gcmVqZWN0IGRyYWZ0LWll
dGYtdGxzLXByb2hpYml0aW5nLXJjNCwgYW5kIHdhaXQgZm9yIHRoZSBSQzQgYXR0YWNrcyB0byBp
bXByb3ZlIGV2ZW4gZnVydGhlci4NCg0KSW4gdGhlIG1lYW50aW1lLCBhbHRlcm5hdGl2ZSBJLURz
IGNhbiBvZiBjb3Vyc2UgYmUgYXV0aG9yZWQgdG8gZGlzY291cmFnZSB0aGUgdXNlIG9mIFJDNCwg
YWx0aG91Z2ggdGhlIFRMUyBCQ1AgYWxyZWFkeSBkb2VzIHNvLg0KDQpUaGFua3MsDQoNCkFuZHJl
aQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IEpvc2VwaCBTYWxvd2V5DQpTZW50OiBTYXR1cmRheSwgT2N0b2JlciAxOCwgMjAxNCAxMTozMyBB
TQ0KVG86IENocmlzIE5ld21hbg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNd
IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdGxzLXByb2hpYml0aW5nLXJjNC0wMS50eHQNCg0KVGhl
IG1haW4gY29uY2VybiB0aGF0IEkgaGF2ZSB3aXRoIHRoaXMgYXBwcm9hY2ggaXMgdGhhdCBhdHRh
Y2tzIGFnYWluc3QgUkM0IHdpbGwgb25seSBnZXQgYmV0dGVyIGFuZCB3aGlsZSB0aGUgYXR0YWNr
cyBtYXkgYmUgY3VycmVudGx5IGltcHJhY3RpY2FsIGFnYWluc3QgSFRUUCBjb29raWVzIHBlcmhh
cHMgdGhlcmUgYXJlIG90aGVyIHVzYWdlcyB3aGVyZSB0aGUgcHJvYmxlbSBtYXkgYmUgZ3JlYXRl
ci4NCg0KUHJhZ21hdGljYWxseSwgaW1wbGVtZW50ZXJzIHdpbGwgZG8gd2hhdCBpcyBuZWNlc3Nh
cnkgdG8gaW50ZXJvcGVyYXRlLCBzbyBJIHRoaW5rIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMg
b2Ygd2hhdCBDaHJpcyByZWNvbW1lbmRzIGJlbG93IG1heSBiZSB0aGUgYmVzdCB3YXkgZm9yd2Fy
ZC4gICAgSSdtIGEgYml0IHJlbHVjdGFudCB0byBicmluZyBvcHBvcnR1bmlzdGljIHNlY3VyaXR5
IGludG8gdGhlIGRpc2N1c3Npb24gYXQgdGhpcyBwb2ludCwgYnV0IEkgdGhpbmsgdGhlIHJlc3Qg
aXMgT0suDQoNCkRvIGZvbGtzIHRoaW5rIHRoaXMgaXMgYW4gYWNjZXB0YWJsZSB3YXkgZm9yd2Fy
ZD8NCg0KVGhhbmtzLA0KDQpKb2UNCg0KDQoNCk9uIFdlZCwgT2N0IDE1LCAyMDE0IGF0IDQ6NDAg
UE0sIENocmlzIE5ld21hbiA8Y2hyaXMubmV3bWFuQG9yYWNsZS5jb208bWFpbHRvOmNocmlzLm5l
d21hbkBvcmFjbGUuY29tPj4gd3JvdGU6DQpJIGFncmVlIHdpdGggdGhpczoNCg0KLS1PbiBPY3Rv
YmVyIDQsIDIwMTQgMzozNTo0NyArMDAwMCBWaWt0b3IgRHVraG92bmkgPGlldGYtZGFuZUBkdWto
b3ZuaS5vcmc8bWFpbHRvOmlldGYtZGFuZUBkdWtob3ZuaS5vcmc+Pg0Kd3JvdGU6DQo+IFdlbGws
IEkgZm9yIG9uZSBhbSBub3QuICAgRGlzYWJsaW5nIFJDNCBkb2VzIG1vcmUgaGFybSB0aGFuIGdv
b2QNCj4gd2l0aCBvcHBvcnR1bmlzdGljIFRMUy4gIEEgZmFyIGJldHRlciBhcHByb2FjaCBpbiB0
aGF0IGNhc2UgaXMgdG8NCj4gZGUtcHJpb3Jpb3JpdGl6ZSBpdC4gIEdpdmluZyBzb21lIGNoZWNr
LWxpc3QgZW5mb3JjaW5nIGNsdWUtbGVzcw0KPiBhdWRpdG9yIHRoZSBhbW11bml0aW9uIHRvIGhh
cmFzcyB1c2VycyBpbnRvIGNvdW50ZXItcHJvZHVjdGl2ZQ0KPiAic2VjdXJpdHkiIG1lYXN1cmVz
IGlzIG5vdCBteSBpZGVhIG9mIHByb2dyZXNzLg0KPiAuLi4NCj4gTm90IGFsbCBhcHBsaWNhdGlv
bnMgZmFjZSB0aGUgc2FtZSByaXNrcywgYW5kIHJlbW92aW5nIFJDNCB3aWxsIHNvbWUNCj4gYXBw
bGljYXRpb25zICpsZXNzKiBzZWN1cmUgYXQgbGVhc3Qgc29tZSBvZiB0aGUgdGltZS4NCg0KQXMg
YW4gaW1wbGVtZW50ZXIgb2YgYSBwcm9kdWN0IHdpdGggVExTL1NTTCBzdXBwb3J0LCBJIHdpbGwg
aWdub3JlIHRoZSB0aHJlZQ0KTVVTVC9NVVNUIE5PVCBzdGF0ZW1lbnRzIGluIHRoaXMgZHJhZnQu
IEFzIGxvbmcgYXMgdGhlIFNTTC9UTFMgbGlicmFyeSBJIHVzZQ0Kc3VwcG9ydHMgUkM0LCBJJ20g
Z29pbmcgdG8gc3VwcG9ydCBSQzQuIEFuZCBJJ2xsIGJlIHJlbHVjdGFudCB0byB1cGdyYWRlIHRv
IGFuDQpTU0wvVExTIGxpYnJhcnkgdGhhdCBkb2Vzbid0IHN1cHBvcnQgUkM0IGZvciBmZWFyIG9m
IGJyZWFraW5nIGN1c3RvbWVyDQppbnRlcm9wZXJhYmlsaXR5IGFuZCBmb3JjaW5nIG9wcG9ydHVu
aXN0aWMgY29ubmVjdGlvbnMgdG8gY2xlYXIgdGV4dC4NCg0KSSBiZWxpZXZlIHRoZSBnb2FsIHNo
b3VsZCBiZSB0byByZXBsYWNlIFJDNCB1c2FnZSBpbiB0aGUgcmVhbCB3b3JsZCB3aXRoIHVzZSBv
Zg0Kc3Ryb25nZXIgY2lwaGVyIHN1aXRlcy4gSSBkbyBub3QgYmVsaWV2ZSB0aGUgY3VycmVudCBk
cmFmdCB3aWxsIGFkdmFuY2UgdGhhdA0KZ29hbC4gU3RhdGVtZW50cyBzaW1pbGFyIHRvIHRoZSBz
aW5nbGUtREVTIGFkdmljZSBpbiBSRkMgNTQ2OSBtYXkgYWR2YW5jZSB0aGF0DQpnb2FsLiBIZXJl
IGFyZSBvdGhlciBzdGF0ZW1lbnRzIHRoYXQgbWF5IGFkdmFuY2UgdGhhdCBnb2FsOg0KDQoqIFNT
TC9UTFMgc29mdHdhcmUgTVVTVCBwcmVmZXIgc3Ryb25nZXIgY2lwaGVyIHN1aXRlcyAocHJlc2Vu
dGx5IEFFUyBhbmQgM0RFUykNCm92ZXIgUkM0Lg0KDQoqIFNTTC9UTFMgbGlicmFyaWVzIE1VU1Qg
ZGlzYWJsZSBSQzQgY2lwaGVyIHN1aXRlcyBieSBkZWZhdWx0LiBBbiBhcHBsaWNhdGlvbg0KTVVT
VCBtYWtlIGFuIGV4cGxpY2l0IFNTTC9UTFMgbGlicmFyeSBBUEkgY2FsbCB0byBlbmFibGUgUkM0
IGNpcGhlciBzdWl0ZXMgaWYNCnRoZXkgYXJlIG5lZWRlZCBmb3IgYmFja3dhcmRzIGNvbXBhdGli
aWxpdHkuDQoNCiogU1NML1RMUyBzb2Z0d2FyZSBNVVNUIGRpc2FibGUgUkM0IGNpcGhlciBzdWl0
ZXMgd2hlbiBUTFMgMS4xIG9yIDEuMiBhcmUNCm5lZ290aWF0ZWQgYW5kIFNIT1VMRCBkaXNhYmxl
IFJDNCBjaXBoZXIgc3VpdGVzIGJ5IGRlZmF1bHQgd2hlbiBlYXJsaWVyDQp2ZXJzaW9ucyBhcmUg
bmVnb3RpYXRlZC4gRm9yIGFuIG9wcG9ydHVuaXN0aWMgc2VjdXJpdHkgdHJhbnNtaXNzaW9uLCBz
dWNoIGFzDQpmb3IgU01UUCByZWxheSAoUkZDIDMyMDcpLCBSQzQgTUFZIGJlIHVzZWQgYXMgYSBs
YXN0IHJlc29ydCBmb3INCmludGVyb3BlcmFiaWxpdHkgcHJpb3IgdG8gZmFsbGJhY2sgdG8gdHJh
bnNtaXNzaW9uIHdpdGhvdXQgU1NML1RMUy4NCg0KKiBVc2VyIGFnZW50cyB0aGF0IGVtcGxveSBT
U0wvVExTIGZvciBzZWN1cml0eSBNVVNUIE5PVCBpbmRpY2F0ZSB0aGUgY29ubmVjdGlvbg0KaXMg
c2VjdXJlIHdoZW4gUkM0IGlzIHVzZWQuIEZvciBleGFtcGxlLCBhIHdlYiBicm93c2VyIHRoYXQg
ZGlzcGxheWVkIGEgbG9jaw0KaWNvbiB3aGVuIGFuIFJDNCBjaXBoZXIgc3VpdGUgd2FzIHVzZWQg
d291bGQgZmFpbCB0byBjb21wbHkgd2l0aCB0aGlzDQpyZXF1aXJlbWVudC4NCg0KICAgICAgICAg
ICAgICAgIC0gQ2hyaXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg0K

--_000_cce9c5f96fe944d5b4f6007d1c4a1bb2BL2PR03MB419namprd03pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uaG9lbnpiDQoJe21z
by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk
aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl
ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o
ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp
diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgaW50ZW50IG9mIGRyYWZ0LWlldGYt
dGxzLXByb2hpYml0aW5nLXJjNCBpcyBleGFjdGx5IHdoYXQgdGhlIHRpdGxlIHNheXM6IHRvIHBy
b2hpYml0IHRoZSB1c2Ugb2YgUkM0LWJhc2VkIGNpcGhlciBzdWl0ZXMgaW4gdGhlIFRMUyBwcm90
b2NvbC4gSW4gcHJhY3RpY2UsDQogcHJvaGliaXRpbmcgUkM0IG1lYW5zIHRoYXQgdGhlIFRMUyBj
bGllbnRzIE1VU1QgTk9UIGFkdmVydGlzZSBSQzQgc3VwcG9ydCwgYW5kIHRoZSBUTFMgc2VydmVy
cyBNVVNUIE5PVCBzZWxlY3QgYW4gUkM0IGNpcGhlciBzdWl0ZS4gQm90aCBwYXJ0cyBhcmUgY3J1
Y2lhbGx5IGltcG9ydGFudCB0byBhY2hpZXZlIHRoZSBwdXJwb3NlIG9mIHRoZSBJLUQuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5JZiB0aGUgVExTIFdHIGNhbm5vdCByZWFjaCByb3VnaCBjb25zZW5zdXMgdGhhdCBSQzQg
Y2lwaGVyIHN1aXRlcyBuZWVkIHRvIGJlIHByb2hpYml0ZWQsIHRoZW4gSSB0aGluayB0aGUgd2F5
IGZvcndhcmQgaXMgZm9yIHRoZSBXRyB0byByZWplY3QgZHJhZnQtaWV0Zi10bHMtcHJvaGliaXRp
bmctcmM0LA0KIGFuZCB3YWl0IGZvciB0aGUgUkM0IGF0dGFja3MgdG8gaW1wcm92ZSBldmVuIGZ1
cnRoZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5JbiB0aGUgbWVhbnRpbWUsIGFsdGVybmF0aXZlIEktRHMgY2FuIG9m
IGNvdXJzZSBiZSBhdXRob3JlZCB0byBkaXNjb3VyYWdlIHRoZSB1c2Ugb2YgUkM0LCBhbHRob3Vn
aCB0aGUgVExTIEJDUCBhbHJlYWR5IGRvZXMgc28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVExT
IFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvc2Vw
aCBTYWxvd2V5PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBPY3RvYmVyIDE4LCAyMDE0IDEx
OjMzIEFNPGJyPg0KPGI+VG86PC9iPiBDaHJpcyBOZXdtYW48YnI+DQo8Yj5DYzo8L2I+IHRsc0Bp
ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gSS1EIEFjdGlvbjogZHJhZnQt
aWV0Zi10bHMtcHJvaGliaXRpbmctcmM0LTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlRoZSBtYWluIGNvbmNlcm4gdGhhdCBJIGhhdmUgd2l0aCB0aGlzIGFwcHJv
YWNoIGlzIHRoYXQgYXR0YWNrcyBhZ2FpbnN0IFJDNCB3aWxsIG9ubHkgZ2V0IGJldHRlciBhbmQg
d2hpbGUgdGhlIGF0dGFja3MgbWF5IGJlIGN1cnJlbnRseSBpbXByYWN0aWNhbCBhZ2FpbnN0IEhU
VFAgY29va2llcyBwZXJoYXBzIHRoZXJlIGFyZSBvdGhlciB1c2FnZXMgd2hlcmUgdGhlIHByb2Js
ZW0gbWF5IGJlIGdyZWF0ZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5QcmFnbWF0aWNhbGx5LCBpbXBsZW1lbnRlcnMgd2lsbCBkbyB3aGF0IGlz
IG5lY2Vzc2FyeSB0byBpbnRlcm9wZXJhdGUsIHNvIEkgdGhpbmsgc29tZXRoaW5nIGFsb25nIHRo
ZSBsaW5lcyBvZiB3aGF0IENocmlzIHJlY29tbWVuZHMgYmVsb3cgbWF5IGJlIHRoZSBiZXN0IHdh
eSBmb3J3YXJkLiAmbmJzcDsgJm5ic3A7SSdtIGEgYml0IHJlbHVjdGFudCB0byBicmluZyBvcHBv
cnR1bmlzdGljIHNlY3VyaXR5IGludG8gdGhlIGRpc2N1c3Npb24NCiBhdCB0aGlzIHBvaW50LCBi
dXQgSSB0aGluayB0aGUgcmVzdCBpcyBPSy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvIGZvbGtzIHRoaW5rIHRoaXMgaXMgYW4g
YWNjZXB0YWJsZSB3YXkgZm9yd2FyZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgT2N0IDE1LCAyMDE0IGF0IDQ6
NDAgUE0sIENocmlzIE5ld21hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLm5ld21hbkBvcmFj
bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMubmV3bWFuQG9yYWNsZS5jb208L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy
Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
IGFncmVlIHdpdGggdGhpczo8YnI+DQo8YnI+DQotLU9uIE9jdG9iZXIgNCwgMjAxNCAzOjM1OjQ3
ICYjNDM7MDAwMCBWaWt0b3IgRHVraG92bmkgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmLWRhbmVA
ZHVraG92bmkub3JnIj5pZXRmLWRhbmVAZHVraG92bmkub3JnPC9hPiZndDs8YnI+DQp3cm90ZTo8
YnI+DQomZ3Q7IFdlbGwsIEkgZm9yIG9uZSBhbSBub3QuJm5ic3A7ICZuYnNwO0Rpc2FibGluZyBS
QzQgZG9lcyBtb3JlIGhhcm0gdGhhbiBnb29kPGJyPg0KJmd0OyB3aXRoIG9wcG9ydHVuaXN0aWMg
VExTLiZuYnNwOyBBIGZhciBiZXR0ZXIgYXBwcm9hY2ggaW4gdGhhdCBjYXNlIGlzIHRvPGJyPg0K
Jmd0OyBkZS1wcmlvcmlvcml0aXplIGl0LiZuYnNwOyBHaXZpbmcgc29tZSBjaGVjay1saXN0IGVu
Zm9yY2luZyBjbHVlLWxlc3M8YnI+DQomZ3Q7IGF1ZGl0b3IgdGhlIGFtbXVuaXRpb24gdG8gaGFy
YXNzIHVzZXJzIGludG8gY291bnRlci1wcm9kdWN0aXZlPGJyPg0KJmd0OyAmcXVvdDtzZWN1cml0
eSZxdW90OyBtZWFzdXJlcyBpcyBub3QgbXkgaWRlYSBvZiBwcm9ncmVzcy48YnI+DQomZ3Q7IC4u
Ljxicj4NCiZndDsgTm90IGFsbCBhcHBsaWNhdGlvbnMgZmFjZSB0aGUgc2FtZSByaXNrcywgYW5k
IHJlbW92aW5nIFJDNCB3aWxsIHNvbWU8YnI+DQomZ3Q7IGFwcGxpY2F0aW9ucyAqbGVzcyogc2Vj
dXJlIGF0IGxlYXN0IHNvbWUgb2YgdGhlIHRpbWUuPGJyPg0KPGJyPg0KQXMgYW4gaW1wbGVtZW50
ZXIgb2YgYSBwcm9kdWN0IHdpdGggVExTL1NTTCBzdXBwb3J0LCBJIHdpbGwgaWdub3JlIHRoZSB0
aHJlZTxicj4NCk1VU1QvTVVTVCBOT1Qgc3RhdGVtZW50cyBpbiB0aGlzIGRyYWZ0LiBBcyBsb25n
IGFzIHRoZSBTU0wvVExTIGxpYnJhcnkgSSB1c2U8YnI+DQpzdXBwb3J0cyBSQzQsIEknbSBnb2lu
ZyB0byBzdXBwb3J0IFJDNC4gQW5kIEknbGwgYmUgcmVsdWN0YW50IHRvIHVwZ3JhZGUgdG8gYW48
YnI+DQpTU0wvVExTIGxpYnJhcnkgdGhhdCBkb2Vzbid0IHN1cHBvcnQgUkM0IGZvciBmZWFyIG9m
IGJyZWFraW5nIGN1c3RvbWVyPGJyPg0KaW50ZXJvcGVyYWJpbGl0eSBhbmQgZm9yY2luZyBvcHBv
cnR1bmlzdGljIGNvbm5lY3Rpb25zIHRvIGNsZWFyIHRleHQuPGJyPg0KPGJyPg0KSSBiZWxpZXZl
IHRoZSBnb2FsIHNob3VsZCBiZSB0byByZXBsYWNlIFJDNCB1c2FnZSBpbiB0aGUgcmVhbCB3b3Js
ZCB3aXRoIHVzZSBvZjxicj4NCnN0cm9uZ2VyIGNpcGhlciBzdWl0ZXMuIEkgZG8gbm90IGJlbGll
dmUgdGhlIGN1cnJlbnQgZHJhZnQgd2lsbCBhZHZhbmNlIHRoYXQ8YnI+DQpnb2FsLiBTdGF0ZW1l
bnRzIHNpbWlsYXIgdG8gdGhlIHNpbmdsZS1ERVMgYWR2aWNlIGluIFJGQyA1NDY5IG1heSBhZHZh
bmNlIHRoYXQ8YnI+DQpnb2FsLiBIZXJlIGFyZSBvdGhlciBzdGF0ZW1lbnRzIHRoYXQgbWF5IGFk
dmFuY2UgdGhhdCBnb2FsOjxicj4NCjxicj4NCiogU1NML1RMUyBzb2Z0d2FyZSBNVVNUIHByZWZl
ciBzdHJvbmdlciBjaXBoZXIgc3VpdGVzIChwcmVzZW50bHkgQUVTIGFuZCAzREVTKTxicj4NCm92
ZXIgUkM0Ljxicj4NCjxicj4NCiogU1NML1RMUyBsaWJyYXJpZXMgTVVTVCBkaXNhYmxlIFJDNCBj
aXBoZXIgc3VpdGVzIGJ5IGRlZmF1bHQuIEFuIGFwcGxpY2F0aW9uPGJyPg0KTVVTVCBtYWtlIGFu
IGV4cGxpY2l0IFNTTC9UTFMgbGlicmFyeSBBUEkgY2FsbCB0byBlbmFibGUgUkM0IGNpcGhlciBz
dWl0ZXMgaWY8YnI+DQp0aGV5IGFyZSBuZWVkZWQgZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5
Ljxicj4NCjxicj4NCiogU1NML1RMUyBzb2Z0d2FyZSBNVVNUIGRpc2FibGUgUkM0IGNpcGhlciBz
dWl0ZXMgd2hlbiBUTFMgMS4xIG9yIDEuMiBhcmU8YnI+DQpuZWdvdGlhdGVkIGFuZCBTSE9VTEQg
ZGlzYWJsZSBSQzQgY2lwaGVyIHN1aXRlcyBieSBkZWZhdWx0IHdoZW4gZWFybGllcjxicj4NCnZl
cnNpb25zIGFyZSBuZWdvdGlhdGVkLiBGb3IgYW4gb3Bwb3J0dW5pc3RpYyBzZWN1cml0eSB0cmFu
c21pc3Npb24sIHN1Y2ggYXM8YnI+DQpmb3IgU01UUCByZWxheSAoUkZDIDMyMDcpLCBSQzQgTUFZ
IGJlIHVzZWQgYXMgYSBsYXN0IHJlc29ydCBmb3I8YnI+DQppbnRlcm9wZXJhYmlsaXR5IHByaW9y
IHRvIGZhbGxiYWNrIHRvIHRyYW5zbWlzc2lvbiB3aXRob3V0IFNTTC9UTFMuPGJyPg0KPGJyPg0K
KiBVc2VyIGFnZW50cyB0aGF0IGVtcGxveSBTU0wvVExTIGZvciBzZWN1cml0eSBNVVNUIE5PVCBp
bmRpY2F0ZSB0aGUgY29ubmVjdGlvbjxicj4NCmlzIHNlY3VyZSB3aGVuIFJDNCBpcyB1c2VkLiBG
b3IgZXhhbXBsZSwgYSB3ZWIgYnJvd3NlciB0aGF0IGRpc3BsYXllZCBhIGxvY2s8YnI+DQppY29u
IHdoZW4gYW4gUkM0IGNpcGhlciBzdWl0ZSB3YXMgdXNlZCB3b3VsZCBmYWlsIHRvIGNvbXBseSB3
aXRoIHRoaXM8YnI+DQpyZXF1aXJlbWVudC48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4
OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtIENocmlzPC9zcGFuPjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUTFMgbWFpbGlu
ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9h
Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxz
IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90
bHM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_cce9c5f96fe944d5b4f6007d1c4a1bb2BL2PR03MB419namprd03pro_--


From nobody Mon Oct 20 17:59:51 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E14F1ACF5F for ; Mon, 20 Oct 2014 17:59:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLroTzTf4EMe for ; Mon, 20 Oct 2014 17:59:48 -0700 (PDT)
Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495AE1ACE8F for ; Mon, 20 Oct 2014 17:59:48 -0700 (PDT)
Received: by mail-yh0-f49.google.com with SMTP id a41so289703yho.8 for ; Mon, 20 Oct 2014 17:59:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y5s+R3cf+9BC/qEc+kObxG5yNQKwcNyqDOsk9bI3Eew=; b=MrEVC8x93zEQqvQ67gg4Q1FLGapkmy7JeZQOYGZ+XcV0IZclcfyXNTaUKmSFQeUBr5 hLvDemFes7u5jPmSzWvecXlAxrb/CyzoRSEji2mrW9ySNNjh3lBFsbkxMOMc3qSJK5wT jIsObIG7WvRAC2fQ5poHqNjie4h6aj2QqlUv3rmb5MYGUsFYIY1hwfWsLcEB4bG8HWEn a+VwBV0Nt14tFi2KxcMTTMgr2XV2nFWfPGS2qS2ryoLgd4oYziP0soHTJwVHhHnPvrns OGrZJZEZvTh8XMCek5dBK4i7/sj1EFKjZke/XwE8U6YswlIasPAqCpYHigsiQx39Xwkh KQPg==
MIME-Version: 1.0
X-Received: by 10.236.1.228 with SMTP id 64mr1622839yhd.51.1413853187488; Mon, 20 Oct 2014 17:59:47 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Mon, 20 Oct 2014 17:59:47 -0700 (PDT)
In-Reply-To: 
References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> <20141004033546.GG13254@mournblade.imrryr.org> <20141002175446.6EB7B1AEA6@ld9781.wdf.sap.corp> <54B025040D4F68B1E49919B8@nifty-silver.us.oracle.com>  
Date: Mon, 20 Oct 2014 17:59:47 -0700
Message-ID: 
From: Watson Ladd 
To: Andrei Popov 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dKfrtkbPoQA1kyg6UCPRoLXorLM
Cc: "tls@ietf.org" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 00:59:50 -0000

On Mon, Oct 20, 2014 at 5:52 PM, Andrei Popov
 wrote:
> The intent of draft-ietf-tls-prohibiting-rc4 is exactly what the title says:
> to prohibit the use of RC4-based cipher suites in the TLS protocol. In
> practice, prohibiting RC4 means that the TLS clients MUST NOT advertise RC4
> support, and the TLS servers MUST NOT select an RC4 cipher suite. Both parts
> are crucially important to achieve the purpose of the I-D.
>
>
>
> If the TLS WG cannot reach rough consensus that RC4 cipher suites need to be
> prohibited, then I think the way forward is for the WG to reject
> draft-ietf-tls-prohibiting-rc4, and wait for the RC4 attacks to improve even
> further.

We've reached consensus RC4 is not a good idea. But, like Saint
Augustine, "grant me strong ciphers, but not today!".
That said, Chris's approach helps get us some of the way there.

Sincerely,
Watson Ladd
>
>
>
> In the meantime, alternative I-Ds can of course be authored to discourage
> the use of RC4, although the TLS BCP already does so.
>
>
>
> Thanks,
>
>
>
> Andrei
>
>
>
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Joseph Salowey
> Sent: Saturday, October 18, 2014 11:33 AM
> To: Chris Newman
> Cc: tls@ietf.org
> Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
>
>
>
> The main concern that I have with this approach is that attacks against RC4
> will only get better and while the attacks may be currently impractical
> against HTTP cookies perhaps there are other usages where the problem may be
> greater.
>
>
>
> Pragmatically, implementers will do what is necessary to interoperate, so I
> think something along the lines of what Chris recommends below may be the
> best way forward.    I'm a bit reluctant to bring opportunistic security
> into the discussion at this point, but I think the rest is OK.
>
>
>
> Do folks think this is an acceptable way forward?
>
>
>
> Thanks,
>
>
>
> Joe
>
>
>
>
>
>
>
> On Wed, Oct 15, 2014 at 4:40 PM, Chris Newman 
> wrote:
>
> I agree with this:
>
> --On October 4, 2014 3:35:47 +0000 Viktor Dukhovni 
> wrote:
>> Well, I for one am not.   Disabling RC4 does more harm than good
>> with opportunistic TLS.  A far better approach in that case is to
>> de-priorioritize it.  Giving some check-list enforcing clue-less
>> auditor the ammunition to harass users into counter-productive
>> "security" measures is not my idea of progress.
>> ...
>> Not all applications face the same risks, and removing RC4 will some
>> applications *less* secure at least some of the time.
>
> As an implementer of a product with TLS/SSL support, I will ignore the three
> MUST/MUST NOT statements in this draft. As long as the SSL/TLS library I use
> supports RC4, I'm going to support RC4. And I'll be reluctant to upgrade to
> an
> SSL/TLS library that doesn't support RC4 for fear of breaking customer
> interoperability and forcing opportunistic connections to clear text.
>
> I believe the goal should be to replace RC4 usage in the real world with use
> of
> stronger cipher suites. I do not believe the current draft will advance that
> goal. Statements similar to the single-DES advice in RFC 5469 may advance
> that
> goal. Here are other statements that may advance that goal:
>
> * SSL/TLS software MUST prefer stronger cipher suites (presently AES and
> 3DES)
> over RC4.
>
> * SSL/TLS libraries MUST disable RC4 cipher suites by default. An
> application
> MUST make an explicit SSL/TLS library API call to enable RC4 cipher suites
> if
> they are needed for backwards compatibility.
>
> * SSL/TLS software MUST disable RC4 cipher suites when TLS 1.1 or 1.2 are
> negotiated and SHOULD disable RC4 cipher suites by default when earlier
> versions are negotiated. For an opportunistic security transmission, such as
> for SMTP relay (RFC 3207), RC4 MAY be used as a last resort for
> interoperability prior to fallback to transmission without SSL/TLS.
>
> * User agents that employ SSL/TLS for security MUST NOT indicate the
> connection
> is secure when RC4 is used. For example, a web browser that displayed a lock
> icon when an RC4 cipher suite was used would fail to comply with this
> requirement.
>
>                 - Chris
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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


From nobody Mon Oct 20 22:14:03 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3094F1AD051 for ; Mon, 20 Oct 2014 22:14:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kx4hMWgai0ye for ; Mon, 20 Oct 2014 22:13:57 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::776]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331011AD050 for ; Mon, 20 Oct 2014 22:13:57 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 21 Oct 2014 05:13:33 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Tue, 21 Oct 2014 05:13:33 +0000
From: Andrei Popov 
To: Watson Ladd 
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: AQHP3c1Ub4FUPtdXakGIHJMHMTXmG5wx5z5wgARg/gCAA4jTEIAAB/SAgABE+8Q=
Date: Tue, 21 Oct 2014 05:13:33 +0000
Message-ID: <1413868526423.88894@microsoft.com>
References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> <20141004033546.GG13254@mournblade.imrryr.org> <20141002175446.6EB7B1AEA6@ld9781.wdf.sap.corp> <54B025040D4F68B1E49919B8@nifty-silver.us.oracle.com>  , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [50.46.226.201]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB420;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0371762FE7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(55674003)(24454002)(51704005)(189002)(377454003)(164054003)(199003)(31966008)(20776003)(64706001)(105586002)(106116001)(66066001)(106356001)(4396001)(99286002)(95666004)(107046002)(110136001)(86612001)(87936001)(230783001)(40100003)(122556002)(76176999)(93886004)(85306004)(54356999)(15975445006)(85852003)(2656002)(19580405001)(19580395003)(50986999)(21056001)(1411001)(92566001)(46102003)(76482002)(92726001)(86362001)(99396003)(80022003)(36756003)(120916001)(101416001)(117636001)(97736003)(22906005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7sswUKTgHPN5Ka0cxF7Kzch-oWM
Cc: "tls@ietf.org" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 05:14:00 -0000

Chris's language reads weaker than the TLS BCP, but if folks want to pursue=
 this, that's up to the WG. My point is that this should be a different I-D=
, because it does not amount to "prohibiting RC4".=0A=
=0A=
Cheers,=0A=
=0A=
Andrei=0A=
________________________________________=0A=
From: Watson Ladd =0A=
Sent: Monday, October 20, 2014 5:59 PM=0A=
To: Andrei Popov=0A=
Cc: Joseph Salowey; Chris Newman; tls@ietf.org=0A=
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt=0A=
=0A=
On Mon, Oct 20, 2014 at 5:52 PM, Andrei Popov=0A=
 wrote:=0A=
> The intent of draft-ietf-tls-prohibiting-rc4 is exactly what the title sa=
ys:=0A=
> to prohibit the use of RC4-based cipher suites in the TLS protocol. In=0A=
> practice, prohibiting RC4 means that the TLS clients MUST NOT advertise R=
C4=0A=
> support, and the TLS servers MUST NOT select an RC4 cipher suite. Both pa=
rts=0A=
> are crucially important to achieve the purpose of the I-D.=0A=
>=0A=
>=0A=
>=0A=
> If the TLS WG cannot reach rough consensus that RC4 cipher suites need to=
 be=0A=
> prohibited, then I think the way forward is for the WG to reject=0A=
> draft-ietf-tls-prohibiting-rc4, and wait for the RC4 attacks to improve e=
ven=0A=
> further.=0A=
=0A=
We've reached consensus RC4 is not a good idea. But, like Saint=0A=
Augustine, "grant me strong ciphers, but not today!".=0A=
That said, Chris's approach helps get us some of the way there.=0A=
=0A=
Sincerely,=0A=
Watson Ladd=0A=
>=0A=
>=0A=
>=0A=
> In the meantime, alternative I-Ds can of course be authored to discourage=
=0A=
> the use of RC4, although the TLS BCP already does so.=0A=
>=0A=
>=0A=
>=0A=
> Thanks,=0A=
>=0A=
>=0A=
>=0A=
> Andrei=0A=
>=0A=
>=0A=
>=0A=
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Joseph Salowey=0A=
> Sent: Saturday, October 18, 2014 11:33 AM=0A=
> To: Chris Newman=0A=
> Cc: tls@ietf.org=0A=
> Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt=0A=
>=0A=
>=0A=
>=0A=
> The main concern that I have with this approach is that attacks against R=
C4=0A=
> will only get better and while the attacks may be currently impractical=
=0A=
> against HTTP cookies perhaps there are other usages where the problem may=
 be=0A=
> greater.=0A=
>=0A=
>=0A=
>=0A=
> Pragmatically, implementers will do what is necessary to interoperate, so=
 I=0A=
> think something along the lines of what Chris recommends below may be the=
=0A=
> best way forward.    I'm a bit reluctant to bring opportunistic security=
=0A=
> into the discussion at this point, but I think the rest is OK.=0A=
>=0A=
>=0A=
>=0A=
> Do folks think this is an acceptable way forward?=0A=
>=0A=
>=0A=
>=0A=
> Thanks,=0A=
>=0A=
>=0A=
>=0A=
> Joe=0A=
>=0A=
>=0A=
>=0A=
>=0A=
>=0A=
>=0A=
>=0A=
> On Wed, Oct 15, 2014 at 4:40 PM, Chris Newman =
=0A=
> wrote:=0A=
>=0A=
> I agree with this:=0A=
>=0A=
> --On October 4, 2014 3:35:47 +0000 Viktor Dukhovni =0A=
> wrote:=0A=
>> Well, I for one am not.   Disabling RC4 does more harm than good=0A=
>> with opportunistic TLS.  A far better approach in that case is to=0A=
>> de-priorioritize it.  Giving some check-list enforcing clue-less=0A=
>> auditor the ammunition to harass users into counter-productive=0A=
>> "security" measures is not my idea of progress.=0A=
>> ...=0A=
>> Not all applications face the same risks, and removing RC4 will some=0A=
>> applications *less* secure at least some of the time.=0A=
>=0A=
> As an implementer of a product with TLS/SSL support, I will ignore the th=
ree=0A=
> MUST/MUST NOT statements in this draft. As long as the SSL/TLS library I =
use=0A=
> supports RC4, I'm going to support RC4. And I'll be reluctant to upgrade =
to=0A=
> an=0A=
> SSL/TLS library that doesn't support RC4 for fear of breaking customer=0A=
> interoperability and forcing opportunistic connections to clear text.=0A=
>=0A=
> I believe the goal should be to replace RC4 usage in the real world with =
use=0A=
> of=0A=
> stronger cipher suites. I do not believe the current draft will advance t=
hat=0A=
> goal. Statements similar to the single-DES advice in RFC 5469 may advance=
=0A=
> that=0A=
> goal. Here are other statements that may advance that goal:=0A=
>=0A=
> * SSL/TLS software MUST prefer stronger cipher suites (presently AES and=
=0A=
> 3DES)=0A=
> over RC4.=0A=
>=0A=
> * SSL/TLS libraries MUST disable RC4 cipher suites by default. An=0A=
> application=0A=
> MUST make an explicit SSL/TLS library API call to enable RC4 cipher suite=
s=0A=
> if=0A=
> they are needed for backwards compatibility.=0A=
>=0A=
> * SSL/TLS software MUST disable RC4 cipher suites when TLS 1.1 or 1.2 are=
=0A=
> negotiated and SHOULD disable RC4 cipher suites by default when earlier=
=0A=
> versions are negotiated. For an opportunistic security transmission, such=
 as=0A=
> for SMTP relay (RFC 3207), RC4 MAY be used as a last resort for=0A=
> interoperability prior to fallback to transmission without SSL/TLS.=0A=
>=0A=
> * User agents that employ SSL/TLS for security MUST NOT indicate the=0A=
> connection=0A=
> is secure when RC4 is used. For example, a web browser that displayed a l=
ock=0A=
> icon when an RC4 cipher suite was used would fail to comply with this=0A=
> requirement.=0A=
>=0A=
>                 - Chris=0A=
>=0A=
>=0A=
> _______________________________________________=0A=
> TLS mailing list=0A=
> TLS@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/tls=0A=
>=0A=
>=0A=
>=0A=
>=0A=
> _______________________________________________=0A=
> TLS mailing list=0A=
> TLS@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/tls=0A=
>=0A=
=0A=
=0A=
=0A=
--=0A=
"Those who would give up Essential Liberty to purchase a little=0A=
Temporary Safety deserve neither  Liberty nor Safety."=0A=
-- Benjamin Franklin=0A=


From nobody Mon Oct 20 22:31:46 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306481AD052 for ; Mon, 20 Oct 2014 22:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.536
X-Spam-Level: 
X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_NUMERIC_HELO=1.164, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnsZDlJEJ-5e for ; Mon, 20 Oct 2014 22:26:51 -0700 (PDT)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420301AD051 for ; Mon, 20 Oct 2014 22:26:50 -0700 (PDT)
Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XgRy4-0002Yp-GK for tls@ietf.org; Tue, 21 Oct 2014 07:26:48 +0200
Received: from 66.87.138.59 ([66.87.138.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Oct 2014 07:26:48 +0200
Received: from eternaleye by 66.87.138.59 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Oct 2014 07:26:48 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: tls@ietf.org
From: Alex Elsayed 
Date: Mon, 20 Oct 2014 22:26:33 -0700
Lines: 52
Message-ID: 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: 66.87.138.59
User-Agent: KNode/4.14
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/svYzugCqYPvBOAVbV9BVpZc2760
X-Mailman-Approved-At: Mon, 20 Oct 2014 22:31:43 -0700
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 05:26:53 -0000

Eric Rescorla wrote:



> Another problem with resumption is that it is a threat to PFS.  In the
> current TLS resumption design, if a session is resumable, then both
> the client and the server retain the MS in their session caches [1].
> Thus, even if you use a PFS cipher suite and destroy the traffic keys
> and the asymmetric keys after the connection is over, an attacker who
> attacks the session cache can decrypt your connection. As noted in my
> previous message, it's not too difficult to separate the MS stored in
> the session cache from the MS used for the initial connection that
> initiated the session, but it's much harder to do so between multiple
> resumptions of the same session, though perhaps we could do figure out
> how to do so [2].



> 
>     Connection 1 does a full asymmetric exchange and establishes
>     session X with MS key M, storing M in the session cache and
>     using M to generate its keys.
> 
>     Connection 2 resumes session X and uses M to generate its keys.
> 
>     Connection 3 resumes session X and uses M to generate its keys.
> 
> It's fairly straightforward to have connection 1 generate two keys,
> M and M' from its PMS, use M to generate its keys and store M'
> in the session cache. But this still leaves both connection 2 and
> 3 sharing M'.

One thing I wonder - do we need to support multiple resumption of the same 
state, or do we simply need to allow a session to die and revive?

The difference is that, in the latter case, we may be able to just evolve 
the MS using some variety of one-way function between each reincarnation of 
a session:

     Connection 1 does a full asymmetric exchange and establishes
     session X with MS key M, storing M' in the session cache and
     using M to generate its keys.

     Connection 2 resumes session X as session X' and uses M' to
     generate its keys, storing M'' in the session cache.
     M' is erased.

     Connection 3 resumes session X' as session X'' and uses M''
     to generate its keys, storing M''' in the session cache.
     M'' is erased.

And so forth.


From SRS0=D4s1=7M=acm.org=bmoeller@srs.kundenserver.de  Mon Oct 20 22:32:39 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406211AD052 for ; Mon, 20 Oct 2014 22:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdM-ve8M6Wv5 for ; Mon, 20 Oct 2014 22:32:38 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC5D1A6F91 for ; Mon, 20 Oct 2014 22:32:36 -0700 (PDT)
Received: from mail-yh0-f46.google.com (mail-yh0-f46.google.com [209.85.213.46]) by mrelayeu.kundenserver.de (node=mreue007) with ESMTP (Nemesis) id 0MU8Wb-1XXGxX2J8r-00QhaA; Tue, 21 Oct 2014 07:32:34 +0200
Received: by mail-yh0-f46.google.com with SMTP id f73so736144yha.19 for ; Mon, 20 Oct 2014 22:32:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.19.69 with SMTP id m45mr19783911yhm.111.1413869553452; Mon, 20 Oct 2014 22:32:33 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Mon, 20 Oct 2014 22:32:33 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 21 Oct 2014 07:32:33 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0160d2cc7e10050505e82896
X-Provags-ID: V02:K0:1rhRJ4NLRMo8yyoFl0lwA8Enatd3RTz6S8GODmMhEFX Zc7sTsbpgCXv6PwB9fj1EW03DHQqyG1PcPxO6Vjiy2c95WyTjv FIdddx4q3Et5Q0mN0ZV/st1gkgCtsDO3+YfFWf9V9N1HWgeFrq JKlwYxd3++7v3BYd6IZ7JYTwe9FaREnkyLXlhX9bF9n0v/8fO5 pH1PjoktXg5MbBTTr7frDa1lpSRXkT++F7yB6G6gcqkI2/lX67 ZuLgwmWmgHOMDrTSp+gxBHWFyLzlx+rzchBT+8v3KyEAlM7OhR W5iLY487b6LOGQd21sjbOmx4PzRGphKFvtGH8ShfUr34+O9Q5D XhXcHSiW0XNukBSZAI2HngNMBhZMnc6NuwoWh4z8Te91KKq2dX B3nh054qVbAVSF3azYi4jDDPImvKOzAkIKjfjA6R1MESqjluaN G/AhE
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QyosCvrj2P1CXfX922AyT6rlzLE
Subject: Re: [TLS] POODLE applicability to TLS 1.0+ (was Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 05:33:14 -0000

--089e0160d2cc7e10050505e82896
Content-Type: text/plain; charset=UTF-8

Brian Smith :

2. The downgrade-scsv draft should be changed to say that implementations
> MUST always send the TLS_FALLBACK_SCSV when ClientHello.client_version
> indicates TLS 1.1 or lower if the client supports TLS 1.2.
>

Maybe, but note that this doesn't actually help against the concrete
problem with old buggy NSS servers (because these don't handle
TLS_FALLBACK_SCSV).

I think that an RFC 2119 "SHOULD" is right for this; if applications ignore
that recommendation willy-nilly, they could also ignore a "MUST". For
strong protection against bugs in old protocol versions, the only option is
to disallow those versions completely.

Bodo

--089e0160d2cc7e10050505e82896
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Bria=
n Smith <brian@briansmith.org>:

2. The downgr=
ade-scsv draft should be changed to say that implementations MUST always se=
nd the TLS_FALLBACK_SCSV when ClientHello.client_version indicates TLS 1.1 =
or lower if the client supports TLS 1.2.

Maybe, but note that this doesn't actually help a=
gainst the concrete problem with old buggy NSS servers (because these don&#=
39;t handle TLS_FALLBACK_SCSV).

I think that an RF=
C 2119 "SHOULD" is right for this; if applications ignore that re=
commendation willy-nilly, they could also ignore a "MUST". For st=
rong protection against bugs in old protocol versions, the only option is t=
o disallow those versions completely.

Bodo



--089e0160d2cc7e10050505e82896--


From nobody Mon Oct 20 22:41:23 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D821AD05B for ; Mon, 20 Oct 2014 22:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2WqRDLngdqC for ; Mon, 20 Oct 2014 22:41:20 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746221A6F91 for ; Mon, 20 Oct 2014 22:41:20 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3EA752AB24B; Tue, 21 Oct 2014 05:41:19 +0000 (UTC)
Date: Tue, 21 Oct 2014 05:41:19 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141021054118.GN19158@mournblade.imrryr.org>
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JVQ8JQY7xZIcbkWznzWkRRVgt7k
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 05:41:21 -0000

On Mon, Oct 20, 2014 at 10:26:33PM -0700, Alex Elsayed wrote:

> > It's fairly straightforward to have connection 1 generate two keys,
> > M and M' from its PMS, use M to generate its keys and store M'
> > in the session cache. But this still leaves both connection 2 and
> > 3 sharing M'.
> 
> One thing I wonder - do we need to support multiple resumption of the same 
> state, or do we simply need to allow a session to die and revive?

In terms of existing practice Postfix resumes cached sessions
independently in parallel.  When a cached a resumed session completes,
no new session replaces the original cache entry.  The code assumes
that session resumption is non-destructive, and cached state can
be re-used multiple times.  I imagine similar behaviour patterns
apply to browsers, and other applications.

If TLS 1.3 changes session re-use semantics, it will be substantially
more difficult to deploy (changes will impact not just SSL library,
but also application code).

-- 
	Viktor.


From nobody Mon Oct 20 22:42:37 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEDB1AD05B for ; Mon, 20 Oct 2014 22:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIFCc1DtaCVZ for ; Mon, 20 Oct 2014 22:42:34 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62841A6F91 for ; Mon, 20 Oct 2014 22:42:33 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id r20so741835wiv.11 for ; Mon, 20 Oct 2014 22:42:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8fXKhhpko0h/1KmDyRTV5efguSfJuNvIlc6QW2qbALw=; b=a1MHAenH/RWJv2q3e9yv9P+RvWz0eYKbIEGu1djFUPXSb0kLlM6NTWblOUZ8OEKWpe VK5w1HfoNAtU8jshPjH0fn8jqGu5X2IJFEITobb6qDdRu8W4y0Thcm3vnJe6ugDne7VV w/fcWuOFvlQp25x+Jp6Y1nqFQSUvjCdLL8GcxbAKAJJnprw79Krth/utL5y4QQaKQZxa WOj/3nXqE8RyO7zCGYSvFZN0TvfUyImEV758DqpMNg6yWv6JJ4xCmPtRwEyS11S1PxE8 vPGJ9KVcmGQYgbWTzOYWoHpQALAZQWWCsQw2A4ugwxOYXA90v0pZveJAC6wzPyOWPIzO Zo9Q==
X-Gm-Message-State: ALoCoQnVpUtQYJJhz+klNtJSkr1UF1YfPhlUoqKRzwr2NaYawmXO9mKV8SRZRCF95JSLHK9jUg5W
X-Received: by 10.194.200.36 with SMTP id jp4mr10627734wjc.114.1413870152447;  Mon, 20 Oct 2014 22:42:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Mon, 20 Oct 2014 22:41:52 -0700 (PDT)
In-Reply-To: 
References:  
From: Eric Rescorla 
Date: Tue, 21 Oct 2014 07:41:52 +0200
Message-ID: 
To: Alex Elsayed 
Content-Type: multipart/alternative; boundary=047d7b8743f6322b340505e84c79
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eKfCxdgKhfZbuapI0YF4u49d5bw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 05:42:36 -0000

--047d7b8743f6322b340505e84c79
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 21, 2014 at 7:26 AM, Alex Elsayed  wrote:

> Eric Rescorla wrote:
>
> 
>
> > Another problem with resumption is that it is a threat to PFS.  In the
> > current TLS resumption design, if a session is resumable, then both
> > the client and the server retain the MS in their session caches [1].
> > Thus, even if you use a PFS cipher suite and destroy the traffic keys
> > and the asymmetric keys after the connection is over, an attacker who
> > attacks the session cache can decrypt your connection. As noted in my
> > previous message, it's not too difficult to separate the MS stored in
> > the session cache from the MS used for the initial connection that
> > initiated the session, but it's much harder to do so between multiple
> > resumptions of the same session, though perhaps we could do figure out
> > how to do so [2].
>
> 
>
> >
> >     Connection 1 does a full asymmetric exchange and establishes
> >     session X with MS key M, storing M in the session cache and
> >     using M to generate its keys.
> >
> >     Connection 2 resumes session X and uses M to generate its keys.
> >
> >     Connection 3 resumes session X and uses M to generate its keys.
> >
> > It's fairly straightforward to have connection 1 generate two keys,
> > M and M' from its PMS, use M to generate its keys and store M'
> > in the session cache. But this still leaves both connection 2 and
> > 3 sharing M'.
>
> One thing I wonder - do we need to support multiple resumption of the same
> state, or do we simply need to allow a session to die and revive?
>
> The difference is that, in the latter case, we may be able to just evolve
> the MS using some variety of one-way function between each reincarnation of
> a session:
>
>      Connection 1 does a full asymmetric exchange and establishes
>      session X with MS key M, storing M' in the session cache and
>      using M to generate its keys.
>
>      Connection 2 resumes session X as session X' and uses M' to
>      generate its keys, storing M'' in the session cache.
>      M' is erased.
>
>      Connection 3 resumes session X' as session X'' and uses M''
>      to generate its keys, storing M''' in the session cache.
>      M'' is erased.
>
> And so forth.


How would erasing the session interact with RFC 5077 tickets?

-Ekr


> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7b8743f6322b340505e84c79
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Oct 21, 2014 at 7:26 AM, Alex Elsayed <eternaleye@gmail.com=
> wrote:
Eric Rescorla wrot=
e:



<snip>



> Another problem with resumption is that it is a threat to PFS.=C2=A0 I=
n the

> current TLS resumption design, if a session is resumable, then both
> the client and the server retain the MS in their session caches [1].
> Thus, even if you use a PFS cipher suite and destroy the traffic keys<=
br>
> and the asymmetric keys after the connection is over, an attacker who<=
br>
> attacks the session cache can decrypt your connection. As noted in my<=
br>
> previous message, it's not too difficult to separate the MS stored=
 in

> the session cache from the MS used for the initial connection that

> initiated the session, but it's much harder to do so between multi=
ple

> resumptions of the same session, though perhaps we could do figure out=


> how to do so [2].



<snip>



>

>=C2=A0 =C2=A0 =C2=A0Connection 1 does a full asymmetric exchange and es=
tablishes

>=C2=A0 =C2=A0 =C2=A0session X with MS key M, storing M in the session c=
ache and

>=C2=A0 =C2=A0 =C2=A0using M to generate its keys.

>

>=C2=A0 =C2=A0 =C2=A0Connection 2 resumes session X and uses M to genera=
te its keys.

>

>=C2=A0 =C2=A0 =C2=A0Connection 3 resumes session X and uses M to genera=
te its keys.

>

> It's fairly straightforward to have connection 1 generate two keys=
,

> M and M' from its PMS, use M to generate its keys and store M'=


> in the session cache. But this still leaves both connection 2 and

> 3 sharing M'.



One thing I wonder - do we need to support multiple resumption of th=
e same

state, or do we simply need to allow a session to die and revive?



The difference is that, in the latter case, we may be able to just evolve
the MS using some variety of one-way function between each reincarnation of=


a session:



=C2=A0 =C2=A0 =C2=A0Connection 1 does a full asymmetric exchange and establ=
ishes

=C2=A0 =C2=A0 =C2=A0session X with MS key M, storing M' in the session =
cache and

=C2=A0 =C2=A0 =C2=A0using M to generate its keys.



=C2=A0 =C2=A0 =C2=A0Connection 2 resumes session X as session X'=
 and uses M' to

=C2=A0 =C2=A0 =C2=A0generate its keys, storing M'' in the session c=
ache.

=C2=A0 =C2=A0 =C2=A0M' is erased.



=C2=A0 =C2=A0 =C2=A0Connection 3 resumes session X' as session X'&#=
39; and uses M''

=C2=A0 =C2=A0 =C2=A0to generate its keys, storing M''' in the s=
ession cache.

=C2=A0 =C2=A0 =C2=A0M'' is erased.



And so forth.

How would erasing the session=
 interact with RFC 5077 tickets?

-Ekr
=
=C2=A0

_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--047d7b8743f6322b340505e84c79--


From nobody Mon Oct 20 22:58:29 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68AC1A6F9C for ; Mon, 20 Oct 2014 22:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXYPqVFIE2Gh for ; Mon, 20 Oct 2014 22:58:27 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 79D491ACE70 for ; Mon, 20 Oct 2014 22:58:27 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 83BEA47547; Tue, 21 Oct 2014 05:58:26 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 7694547544; Tue, 21 Oct 2014 05:58:26 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 7152D8003C; Tue, 21 Oct 2014 05:58:26 +0000 (GMT)
Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 21 Oct 2014 01:58:26 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Tue, 21 Oct 2014 01:58:25 -0400
From: "Salz, Rich" 
To: Andrei Popov , Watson Ladd 
Date: Tue, 21 Oct 2014 01:58:23 -0400
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: AQHP3c1Ub4FUPtdXakGIHJMHMTXmG5wx5z5wgARg/gCAA4jTEIAAB/SAgABE+8SAAA374A==
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C495B@USMBX1.msg.corp.akamai.com>
References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> <20141004033546.GG13254@mournblade.imrryr.org> <20141002175446.6EB7B1AEA6@ld9781.wdf.sap.corp> <54B025040D4F68B1E49919B8@nifty-silver.us.oracle.com>  ,  <1413868526423.88894@microsoft.com>
In-Reply-To: <1413868526423.88894@microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Gv8qB8cKF6FkrIUnhBoS9T4V0B4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 05:58:28 -0000

> Chris's language reads weaker than the TLS BCP, but if folks want to purs=
ue
> this, that's up to the WG. My point is that this should be a different I-=
D,
> because it does not amount to "prohibiting RC4".

+1

Kill RC4 or put our face on it and face the public embarrassment.

It is clearly a best practice to not use RC4. Sure, some clients and server=
s have no choice and have to do so. So what?  The Internet is full of syste=
ms that do not follow best practices. That should not change what the "best=
" practice is.


From nobody Mon Oct 20 23:00:07 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC11E1ACE70 for ; Mon, 20 Oct 2014 23:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtX99IlmoqB4 for ; Mon, 20 Oct 2014 23:00:05 -0700 (PDT)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5909E1A6F9C for ; Mon, 20 Oct 2014 23:00:05 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id l4so366263lbv.40 for ; Mon, 20 Oct 2014 23:00:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pYjo8165iXJo3qK/eDNAY/xN/SQM0hpjhY9utVYHzC0=; b=LzgU9MwUM6czp/saAU60jew1CRJSIqnp5Uwy4gbhUc/umy7gGf3AlsrJnFsdpLw4WC NuRfMmKk5uWuoZZhbxvGHBy3areFzV4xC1JW6Be8DbRtlWhF9MWKMorqqj+9s6/V/lYe 5E9rz1bPYitOACik7u8kklnk1epqPeAUr1yT1W+0NJ53HVJRwQ+T7ha8AEjnmzmVvTIG qwa1U8DQlaFXIA6L4FKHDTB7Fq16c/UNM0klzIA3QekIg7YJ+r65Sx4cuoZKXfmJ5mPn ZeuhmgS0c04TZrZikEFxWJrnBJNZ0F54UTq3c6kp88TmBNjr/KxdIkgloO12ScuW1ANh JnnA==
MIME-Version: 1.0
X-Received: by 10.152.27.38 with SMTP id q6mr702773lag.92.1413871203659; Mon, 20 Oct 2014 23:00:03 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Mon, 20 Oct 2014 23:00:03 -0700 (PDT)
In-Reply-To: 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> 
Date: Mon, 20 Oct 2014 23:00:03 -0700
Message-ID: 
From: Martin Thomson 
To: Brian Smith 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/er3nOHrhhn0Jpunwv3pn3Ww7N5k
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 06:00:06 -0000

On 20 October 2014 16:34, Brian Smith  wrote:
> +  The client MUST always include an empty Session ID in the ClientHello.
> +  The server MUST always include an empty Session ID in the ServerHello.
> +  The client determines if the server is resuming a session by
>    the subsequent handshake messages.

I'm going to suggest going one further.  Remove the session ID from
the ServerHello entirely.


From nobody Mon Oct 20 23:05:28 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63DB1AD065 for ; Mon, 20 Oct 2014 23:05:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-bej__XSCsh for ; Mon, 20 Oct 2014 23:05:23 -0700 (PDT)
Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A991AD064 for ; Mon, 20 Oct 2014 23:05:23 -0700 (PDT)
Received: by mail-yh0-f54.google.com with SMTP id 29so888841yhl.13 for ; Mon, 20 Oct 2014 23:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8/bL49P0Sv6w6v1BbXBjDqG3zciLKF/14ZvN4BCm+p4=; b=Jid9ldZ7HzCvnoodlEM0OLN85G1d9SPMaH3AHFcITJECfsHoQvRv/zc0VsqymWFoqi gIBFIY0U0AFHFf9OQMeBkPM++70ezLL7JaUF3ldVTYebSd07ElbJM2vErJECMv5oMIee 4/E1M+kk48jol4O/7+mpN85F/1/PwHih7p7u1CGQ9IEmhf3tGeFbpXJY6aVo2jlRqbzP F0knF492PtqY4az17w5VQ3PxbjBwfyAMFkik7jScAQBMOjqBRDrOz5BeA4dA6oQT2657 u2IbAKaYjtII+Qi5IHvOwB1CZTEqMG5Vk5U7DVhvfmPO8YeJUV4B9rSdr+Bnle+BEKh2 2niw==
MIME-Version: 1.0
X-Received: by 10.236.199.46 with SMTP id w34mr46666144yhn.20.1413871522762; Mon, 20 Oct 2014 23:05:22 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Mon, 20 Oct 2014 23:05:22 -0700 (PDT)
In-Reply-To: <20141021054118.GN19158@mournblade.imrryr.org>
References:   <20141021054118.GN19158@mournblade.imrryr.org>
Date: Mon, 20 Oct 2014 23:05:22 -0700
Message-ID: 
From: Watson Ladd 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uLzd0lNkE3hLSjV7kM_Imm1yW7I
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 06:05:26 -0000

On Mon, Oct 20, 2014 at 10:41 PM, Viktor Dukhovni
 wrote:
> On Mon, Oct 20, 2014 at 10:26:33PM -0700, Alex Elsayed wrote:
>
>> > It's fairly straightforward to have connection 1 generate two keys,
>> > M and M' from its PMS, use M to generate its keys and store M'
>> > in the session cache. But this still leaves both connection 2 and
>> > 3 sharing M'.
>>
>> One thing I wonder - do we need to support multiple resumption of the same
>> state, or do we simply need to allow a session to die and revive?
>
> In terms of existing practice Postfix resumes cached sessions
> independently in parallel.  When a cached a resumed session completes,
> no new session replaces the original cache entry.  The code assumes
> that session resumption is non-destructive, and cached state can
> be re-used multiple times.  I imagine similar behaviour patterns
> apply to browsers, and other applications.
>
> If TLS 1.3 changes session re-use semantics, it will be substantially
> more difficult to deploy (changes will impact not just SSL library,
> but also application code).

In a little over an hour a meeting on this topic will be starting, so
let me put in my two cents. There is no reason a resumed session needs
to use the same keys as the record layer of the session that was
resumed. (Actually, there is, namely 0-RTT, but lets forget that for
the time being/solve it some other way). In particular having a
connection generate a resumption key, and deriving from the resumption
key new, distinct, keys for each direction of the new communication
solves the PFS problem, while still enabling multiple resumption.

Furthermore, resumption has always been optional. TLS 1.2 states that
a client does not know if a server will permit resumption. Likewise, a
server doesn't know if a client supports resumption. That said, adding
mutability to something that wasn't mutable is a major change in
multithreaded code, and should be avoided.

Sincerely,
Watson Ladd
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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


From nobody Mon Oct 20 23:11:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888681AD066 for ; Mon, 20 Oct 2014 23:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy_o4l4YJHdR for ; Mon, 20 Oct 2014 23:11:32 -0700 (PDT)
Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272C01AD065 for ; Mon, 20 Oct 2014 23:11:32 -0700 (PDT)
Received: by mail-oi0-f47.google.com with SMTP id a141so409448oig.20 for ; Mon, 20 Oct 2014 23:11:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n7Ic+EenHZeP2kxNqDNcehOSsGEPB8b+tGq6yqC4d2Q=; b=KdXb+cndPMmhy440/b3h3GugSJkNyirbkRx4eO6dprrM+72UgjVXJFDoLbV5BpxeIK ZTxkhAmKpNn8pVTb8/EIrvtbeYkstNj8NOqVbj0Ene04Zn7qMHLtrGnwnNF6mGxbbu1b 7/+pdr2H1x01O/PQe8VgZS7jN1wJh/UkP73etKsJJTQRomow6yhs/F0pcnoPlseO69O2 EF1PMOGYO4XIYsZKS5iT3CtalDIRRH7NWyyBG5j50cfX9NNGnaAJJOjbnYETmNWArDmd 02DlhmfA/trF2rhO9oyzmFzw5Aef9caMMyxHWFk+yJouXXNjwYhwqWow35oPSttovtfz jphw==
X-Gm-Message-State: ALoCoQkM+QNAWhyAsHaSwCp6ULRcyTsz9PR41j1jrJkCLNxPvMniLifpZIj/RtjuMsRacAcUBmuD
MIME-Version: 1.0
X-Received: by 10.60.146.147 with SMTP id tc19mr605415oeb.49.1413871891622; Mon, 20 Oct 2014 23:11:31 -0700 (PDT)
Received: by 10.76.93.9 with HTTP; Mon, 20 Oct 2014 23:11:31 -0700 (PDT)
In-Reply-To: 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  
Date: Mon, 20 Oct 2014 23:11:31 -0700
Message-ID: 
From: Brian Smith 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=047d7b5d42fedbc4280505e8b3de
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GwQ2uvBSH_MqLpvdOEHSOORV8Bk
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 06:11:33 -0000

--047d7b5d42fedbc4280505e8b3de
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 20, 2014 at 11:00 PM, Martin Thomson 
wrote:

> On 20 October 2014 16:34, Brian Smith  wrote:
> > +  The client MUST always include an empty Session ID in the ClientHello.
> > +  The server MUST always include an empty Session ID in the ServerHello.
> > +  The client determines if the server is resuming a session by
> >    the subsequent handshake messages.
>
> I'm going to suggest going one further.  Remove the session ID from
> the ServerHello entirely.
>

That would be dependent on having TLS 1.3 use a different value from TLS
1.2 in the ServerHello.server_version field, which appears to cause too
many interop problems to be viable. To avoid creating unnecessary interop
problems, it is better to make the TLS 1.3 handshakes look as much like TLS
1.2 resumption handshakes as possible. Or, at least, avoid making
gratuitous changes to the format of ServerHello and other plaintext
messages.

Cheers,
Brian

--047d7b5d42fedbc4280505e8b3de
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Oct 20, 2014 at 11:00 PM, Martin Thomson <martin.thomson@gmail=
.com> wrote:
On 20 October 2014 16:34, Brian Smith <brian@briansmith.org> wrote:

> +=C2=A0 The client MUST always include an empty Session ID in the Clie=
ntHello.

> +=C2=A0 The server MUST always include an empty Session ID in the Serv=
erHello.

> +=C2=A0 The client determines if the server is resuming a session by
>=C2=A0 =C2=A0 the subsequent handshake messages.



I'm going to suggest going one further.=C2=A0 Remove the session=
 ID from

the ServerHello entirely.



That would be depen=
dent on having TLS 1.3 use a different value from TLS 1.2 in the ServerHell=
o.server_version field, which appears to cause too many interop problems to=
 be viable. To avoid creating unnecessary interop problems, it is better to=
 make the TLS 1.3 handshakes look as much like TLS 1.2 resumption handshake=
s as possible. Or, at least, avoid making gratuitous changes to the format =
of ServerHello and other plaintext messages.

Cheers,
Brian



--047d7b5d42fedbc4280505e8b3de--


From nobody Mon Oct 20 23:12:00 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3741AD06E for ; Mon, 20 Oct 2014 23:11:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level: 
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afKFWbI3Zkti for ; Mon, 20 Oct 2014 23:11:56 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 849C31AD06B for ; Mon, 20 Oct 2014 23:11:56 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DDDB4284EB; Tue, 21 Oct 2014 06:11:55 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id C4268284E6; Tue, 21 Oct 2014 06:11:55 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id B19EB80047; Tue, 21 Oct 2014 06:11:55 +0000 (GMT)
Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 21 Oct 2014 02:11:55 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Tue, 21 Oct 2014 02:11:54 -0400
From: "Salz, Rich" 
To: =?iso-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , "Richard Fussenegger, BSc" , "TLS@ietf.org (tls@ietf.org)" 
Date: Tue, 21 Oct 2014 02:11:53 -0400
Thread-Topic: [TLS] Unifying tickets and sessions
Thread-Index: Ac/srlnPdmHmFxdrRXOgpmQINamKiwAR2kFQ
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4960@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org>
In-Reply-To: <54458113.1050304@polarssl.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sHyAzVm6PGhliaNU1Tl2qF3xtSg
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 06:11:57 -0000

I think the spec should mention the issues of re-using keys.  But it should=
 stay silent on which crypto suite to use.  It's totally a server issue; it=
 could use ROT-13 if it wanted.


-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Mon Oct 20 23:15:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41261AD065 for ; Mon, 20 Oct 2014 23:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5slkMQxNehM6 for ; Mon, 20 Oct 2014 23:15:35 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 797C81AD062 for ; Mon, 20 Oct 2014 23:15:35 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 18B5D47522; Tue, 21 Oct 2014 06:15:35 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 0B0B6474EB; Tue, 21 Oct 2014 06:15:35 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 069A98003C; Tue, 21 Oct 2014 06:15:35 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 21 Oct 2014 02:15:17 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Tue, 21 Oct 2014 02:15:16 -0400
From: "Salz, Rich" 
To: Brian Smith , Martin Thomson 
Date: Tue, 21 Oct 2014 02:15:14 -0400
Thread-Topic: [TLS] Unifying tickets and sessions
Thread-Index: Ac/s9d8mpItyUf/0SXOXGd5uBOp0ngAAHTQQ
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4962@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3mrgPm31S33Yda3MAiy0apJ_vC4
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 06:15:36 -0000

SSBhZ3JlZSB3aXRoIEJyaWFuLCBzYXZpbmcgdGhlIGZpZWxkIHNlZW1zIGxpa2UgdGhlIHdyb25n
IGludGVyb3AgdHJhZGVvZmYuDQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlciwg
QWthbWFpIFRlY2hub2xvZ2llcw0KSU06IHJzYWx6QGphYmJlci5tZSBUd2l0dGVyOiBSaWNoU2Fs
eg0KDQoNCg==


From nobody Mon Oct 20 23:21:55 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495621AD065 for ; Mon, 20 Oct 2014 23:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUZvujNz5Psk for ; Mon, 20 Oct 2014 23:21:51 -0700 (PDT)
Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370AA1AD012 for ; Mon, 20 Oct 2014 23:21:51 -0700 (PDT)
Received: by mail-ob0-f169.google.com with SMTP id m8so437267obr.14 for ; Mon, 20 Oct 2014 23:21:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lhbNHiXR/tQo7PzsOpgQPmKNMHxrZybu557l+CtGX7o=; b=F/wJer12s9GQgKlmXaIEQoK5ZTRtBpF1WVeeLEJRywybyXKWJ+cyGn7YF1Nm/0FrhT JZHoUTJ/p58k5EuEpmJDlgD/LoUgc7+TKfSlknR5Sd/6sktc2QvzAgBS7j71cDKlvFiK 4y59oV+VjucuTrGca7DyFtglG6bnDwPk9LNrzzR/8ZNUKmh2HEdqacIVnAlpBiznMDzH lFCiwt/um+bfQM+zd24/IRY2uZjfZcdDXG+Pgf3MJu3AM+LhRP2QHmswVU6YRZxyLh0Y dAP3iYDK1Grp/LnKTkgfJOWPDZzZKhbMWOP//4soxKVU8P4O8qZsjhc8jPFWn2Wp69yV z4HQ==
X-Gm-Message-State: ALoCoQnxO8e7vp17CUMWsqGxdnOaXEZdJgcjAG1MH36NRVyYFXxEG4JJWjJc2hU3ef7Tjle2Svkc
MIME-Version: 1.0
X-Received: by 10.182.245.225 with SMTP id xr1mr27787542obc.13.1413872510578;  Mon, 20 Oct 2014 23:21:50 -0700 (PDT)
Received: by 10.76.93.9 with HTTP; Mon, 20 Oct 2014 23:21:50 -0700 (PDT)
In-Reply-To: 
References:  
Date: Mon, 20 Oct 2014 23:21:50 -0700
Message-ID: 
From: Brian Smith 
To: Bodo Moeller 
Content-Type: multipart/alternative; boundary=001a11c1c970c04aa30505e8d85e
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pXTaHrevXLE4JOtNja7O3TvFPqY
Cc: "tls@ietf.org" 
Subject: Re: [TLS] POODLE applicability to TLS 1.0+ (was Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 06:21:53 -0000

--001a11c1c970c04aa30505e8d85e
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 20, 2014 at 10:32 PM, Bodo Moeller  wrote:

> Brian Smith :
>
> 2. The downgrade-scsv draft should be changed to say that implementations
>> MUST always send the TLS_FALLBACK_SCSV when ClientHello.client_version
>> indicates TLS 1.1 or lower if the client supports TLS 1.2.
>>
>
> Maybe, but note that this doesn't actually help against the concrete
> problem with old buggy NSS servers (because these don't handle
> TLS_FALLBACK_SCSV).
>

First of all, even that old version of NSS is not buggy, according to the
spec. My main concern isn't with old versions of NSS. My main concern is
that we do not know how many TLS 1.0 servers actually check the padding,
but we've assumed that all of them do, even though TLS 1.0 does not require
checking the padding.

Note that a 100% conformant TLS 1.0 implementation could add
TLS_FALLBACK_SCSV support exactly as spec'd and still be vulnerable to
POODLE if it doesn't check the padding in CBC-mode records. Again, I think
this is something worth adding to the security considerations of the
TLS_FALLBACK_SCSV draft.

For strong protection against bugs in old protocol versions, the only
> option is to disallow those versions completely.
>

Yes, but TLS 1.0 implementations can mitigate the risk, as most do, by
checking the padding conforms to the TLS 1.0 requirements.

And, so can SSL 3.0 implementations, right? Checking that SSL 3.0 CBC-mode
records conform to the TLS 1.0 padding rules is likely to cause some
interop problems, but those interop problems would be much less severe than
disabling SSL 3.0 completely, right? I checked and most implementations of
SSL 3.0 are following the TLS 1.0 padding rules in records that they send,
including IE6 on XP, AFAICT. It seems to me that that is a better solution
for websites that refuse to disable SSL 3.0 because they feel they need IE6
support, compared to switching to RC4-only for SSL 3.0. What do you think?

Cheers,
Brian

--001a11c1c970c04aa30505e8d85e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Oct 20, 2014 at 10:32 PM, Bodo Moeller <bmoeller@acm.org>=
 wrote:
Brian Smith <brian@briansmith.org>:

=

2. The downgrade-scsv draft should be chang=
ed to say that implementations MUST always send the TLS_FALLBACK_SCSV when =
ClientHello.client_version indicates TLS 1.1 or lower if the client support=
s TLS 1.2.

M=
aybe, but note that this doesn't actually help against the concrete pro=
blem with old buggy NSS servers (because these don't handle TLS_FALLBAC=
K_SCSV).

First of a=
ll, even that old version of NSS is not buggy, according to the spec. My ma=
in concern isn't with old versions of NSS. My main concern is that we d=
o not know how many TLS 1.0 servers actually check the padding, but we'=
ve assumed that all of them do, even though TLS 1.0 does not require checki=
ng the padding.

Note that a 100% conformant TLS 1.=
0 implementation could add TLS_FALLBACK_SCSV support exactly as spec'd =
and still be vulnerable to POODLE if it doesn't check the padding in CB=
C-mode records. Again, I think this is something worth adding to the securi=
ty considerations of the TLS_FALLBACK_SCSV draft.

For strong protection against bugs in old protocol versions, t=
he only option is to disallow those versions completely.
<=
/div>

Yes, but TLS 1.0 implementations can =
mitigate the risk, as most do, by checking the padding conforms to the TLS =
1.0 requirements.=C2=A0

And, so can SSL 3.0 implem=
entations, right? Checking that SSL 3.0 CBC-mode records conform to the TLS=
 1.0 padding rules is likely to cause some interop problems, but those inte=
rop problems would be much less severe than disabling SSL 3.0 completely, r=
ight? I checked and most implementations of SSL 3.0 are following the TLS 1=
.0 padding rules in records that they send, including IE6 on XP, AFAICT. It=
 seems to me that that is a better solution for websites that refuse to dis=
able SSL 3.0 because they feel they need IE6 support, compared to switching=
 to RC4-only for SSL 3.0. What do you think?

Cheer=
s,
Brian


--001a11c1c970c04aa30505e8d85e--


From nobody Tue Oct 21 00:05:56 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EF61AD09D for ; Tue, 21 Oct 2014 00:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0OZ3tuqjtDO for ; Tue, 21 Oct 2014 00:05:38 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69E51AD069 for ; Tue, 21 Oct 2014 00:05:36 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id y10so572448wgg.3 for ; Tue, 21 Oct 2014 00:05:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=A+PYMF26/PtfFVWOiBqtNCTOTUNZeYMjachy8yxLilE=; b=jiMH9jq/3HF33xmIrDEHwUeYuuc+YIcfQZq3egGm2Fp9/KAwY1+1uRbU03XgzQ/s4n cdyUpQJJ2ercHhQZCLXfh3lE/hJJO/0atfvbvto/v8jYHko0zC4T99Q604+D5Dwp67X6 3oWyDG3QTrMJGD1Nd95uWiVgbFo/FSUGk4QLh7fzPvHkaR1DNvIoKIAu5GYXnt4ODRkh usOcfoAJVk3s7LeIDKg7jCMe1qPdRH1/LJ62fVJqM/anzhHOxh+XpdFcp6GIVnneLaFL HJyyEdabX2Jws0Nahhm0K6TtvVxAhpXOS/CzjEFZ7fEeWdJMNC3/ictdtQRmD6tUUEIy CwBA==
X-Gm-Message-State: ALoCoQnJZoSoYnptX3nfsqL8pLo/tCa8BA5skaV8reFKZXyToOMnb80D7X+nDICuC5l8MQLgWjeu
X-Received: by 10.180.104.8 with SMTP id ga8mr25854349wib.78.1413875134844; Tue, 21 Oct 2014 00:05:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Tue, 21 Oct 2014 00:04:54 -0700 (PDT)
In-Reply-To: 
References:   <20141021054118.GN19158@mournblade.imrryr.org> 
From: Eric Rescorla 
Date: Tue, 21 Oct 2014 09:04:54 +0200
Message-ID: 
To: Watson Ladd 
Content-Type: multipart/alternative; boundary=f46d044271302b841e0505e97511
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_q4KeCCf9v8Onfe9y-UtKobZye8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fate of resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 07:05:43 -0000

--f46d044271302b841e0505e97511
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 21, 2014 at 8:05 AM, Watson Ladd  wrote:

> On Mon, Oct 20, 2014 at 10:41 PM, Viktor Dukhovni
>  wrote:
> > On Mon, Oct 20, 2014 at 10:26:33PM -0700, Alex Elsayed wrote:
> >
> >> > It's fairly straightforward to have connection 1 generate two keys,
> >> > M and M' from its PMS, use M to generate its keys and store M'
> >> > in the session cache. But this still leaves both connection 2 and
> >> > 3 sharing M'.
> >>
> >> One thing I wonder - do we need to support multiple resumption of the
> same
> >> state, or do we simply need to allow a session to die and revive?
> >
> > In terms of existing practice Postfix resumes cached sessions
> > independently in parallel.  When a cached a resumed session completes,
> > no new session replaces the original cache entry.  The code assumes
> > that session resumption is non-destructive, and cached state can
> > be re-used multiple times.  I imagine similar behaviour patterns
> > apply to browsers, and other applications.
> >
> > If TLS 1.3 changes session re-use semantics, it will be substantially
> > more difficult to deploy (changes will impact not just SSL library,
> > but also application code).
>
> In a little over an hour a meeting on this topic will be starting, so
> let me put in my two cents. There is no reason a resumed session needs
> to use the same keys as the record layer of the session that was
> resumed. (Actually, there is, namely 0-RTT, but lets forget that for
> the time being/solve it some other way). In particular having a
> connection generate a resumption key, and deriving from the resumption
> key new, distinct, keys for each direction of the new communication
> solves the PFS problem, while still enabling multiple resumption.
>

It solves the PFS problem between the connection that established
the session and the next session. However, as long as the keys
for resumed connection 1 and connection 2 are derived from the
same keying material, then you have a PFS problem between
connections #1 and #2.

-Ekr

--f46d044271302b841e0505e97511
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Oct 21, 2014 at 8:05 AM, Watson Ladd <watsonbladd@gmail.co=
m> wrote:
=
On Mon, Oct 20, 2014 at 10:41 PM, Viktor Dukhovni

<ietf-dane@dukhovni.org>=
; wrote:

> On Mon, Oct 20, 2014 at 10:26:33PM -0700, Alex Elsayed wrote:

>

>> > It's fairly straightforward to have connection 1 generate=
 two keys,

>> > M and M' from its PMS, use M to generate its keys and sto=
re M'

>> > in the session cache. But this still leaves both connection 2=
 and

>> > 3 sharing M'.

>>

>> One thing I wonder - do we need to support multiple resumption of =
the same

>> state, or do we simply need to allow a session to die and revive?<=
br>
>

> In terms of existing practice Postfix resumes cached sessions

> independently in parallel.=C2=A0 When a cached a resumed session compl=
etes,

> no new session replaces the original cache entry.=C2=A0 The code assum=
es

> that session resumption is non-destructive, and cached state can

> be re-used multiple times.=C2=A0 I imagine similar behaviour patterns<=
br>
> apply to browsers, and other applications.

>

> If TLS 1.3 changes session re-use semantics, it will be substantially<=
br>
> more difficult to deploy (changes will impact not just SSL library,
> but also application code).



In a little over an hour a meeting on this topic will be starting, s=
o

let me put in my two cents. There is no reason a resumed session needs

to use the same keys as the record layer of the session that was

resumed. (Actually, there is, namely 0-RTT, but lets forget that for

the time being/solve it some other way). In particular having a

connection generate a resumption key, and deriving from the resumption

key new, distinct, keys for each direction of the new communication

solves the PFS problem, while still enabling multiple resumption.

It solves the PFS problem between the connection=
 that established
the session and the next session. However, as l=
ong as the keys
for resumed connection 1 and connection 2 are der=
ived from the
same keying material, then you have a PFS problem b=
etween
connections #1 and #2.=C2=A0

-Ekr=




--f46d044271302b841e0505e97511--


From nobody Tue Oct 21 00:10:56 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EF41AD06E for ; Tue, 21 Oct 2014 00:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fGvqCA7Pke9 for ; Tue, 21 Oct 2014 00:10:52 -0700 (PDT)
Received: from mx207.easyname.com (mx207.easyname.com [212.232.25.163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA2C1AD09A for ; Tue, 21 Oct 2014 00:10:51 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgTah-0008Rr-NO for tls@ietf.org; Tue, 21 Oct 2014 09:10:49 +0200
Message-ID: <544606E5.2070807@fussenegger.info>
Date: Tue, 21 Oct 2014 09:10:29 +0200
From: "Richard Fussenegger, BSc" 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org>
In-Reply-To: <20141020235832.GK19158@mournblade.imrryr.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000706070900010307060308"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fjv9TP7avHo9EcpCvdJDqKJ2GeE
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 07:10:54 -0000

This is a cryptographically signed message in MIME format.

--------------ms000706070900010307060308
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

I was to vague in regards to implementation, sorry. Of course we only=20
want a single key or rather one long blob of random data to manage. The=20
idea of using a key length of at least the 'highest supported=20
ciphers'[*] sounds very good to me and would honor the ciphers in use.=20
By always using a 128 bit key (current OpenSSL implementation) higher=20
ciphers are essentially downgraded.

[*] Better would be 'from all ciphers in use' otherwise one ends up with =

a (insert ridiculous high value here) bit key while only using 128 bit=20
ciphers in the configuration. Dropping the key if a new stronger=20
configuration is loaded seems like a good idea to me at this point. I'm=20
looking at this from a performance perspective and glimpsing over to the =

fact that the cryptography community agrees that 128 bit security will=20
be enough for the next 10 to 20 years.[2] I really can't tell if this=20
would be problematic from an implementation point of view. I think that=20
single hosts won't have a problem here and I guess that it wouldn't be=20
for clusters as well. The cluster configuration should be in sync but it =

could become a problem if one node has a differing configuration (for=20
whatever reason). What opinion/insights do you have on this?

Regards
Richard

[1] http://www.keylength.com/

On 10/21/2014 1:58 AM, Viktor Dukhovni wrote:
> On Mon, Oct 20, 2014 at 11:39:31PM +0200, Manuel P?gouri?-Gonnard wrote=
:
>
>>> The RFC should clarify that the negotiated cipher **MUST** be honored=

>>> when encrypting the state that will be sent to the client. [1]
> I am having trouble parsing the original suggestion above.
>
>> While I'm sympathetic with the goal, I'm afraid that will complicate
>> implementations more than necessary. How about requiring to use a key =
length at
>> least a high as the highest supported ciphersuite instead?
> Does it mean (as I think you're saying) that session tickets MUST
> be encrypted with the session's negotiated ciphersuite?  That seems
> rather unmanageable.  A single sufficiently strong key is likely
> far more realistic.
>
> With keys for clusters of servers rotated by code external to the
> TLS library, asking for a key for every algorith/size is impractical.
>



--------------ms000706070900010307060308
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjEwNzEwMjlaMCMGCSqGSIb3DQEJBDEWBBQKbYlPh6g1AuevJ4kk02av0E1p2TBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEAv/MP4RPC225KZH5gHz98v0OPrJHt
EQAxlBfDlEl/r1AqMA+O3+Vz5qGJXj3yV/tfmoTyCtFxOKxyY6NIKefURYsnMq3TagdpE5Z9
G57Gh/DEW/5CW2vVhpm/2jfdE8bCTU9pJULn/QT1scUJ+Y8gUsXTvaLcDuR8XIcayyerdSig
IdfChzI+D/g6B1deZLbxOux5vU6yFTxp3wDmlyNFdUVHORENIMZCpqULPLY8FsdDmBrYNfj/
8QWBi5mJmbuhPvDeVTS5F9MnvQe2i/FwIO9I0IXEqL2goPjIVJ5bfLTGDdBn0FGSsN1Me6/f
CMW0zo1MunhUIWL12ZHhkuSynQAAAAAAAA==
--------------ms000706070900010307060308--


From nobody Tue Oct 21 00:19:09 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1A1A6FBF for ; Tue, 21 Oct 2014 00:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClslL8KjtG46 for ; Tue, 21 Oct 2014 00:19:07 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38401AD068 for ; Tue, 21 Oct 2014 00:19:06 -0700 (PDT)
Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0McWDw-1XOwps290i-00Hf7r; Tue, 21 Oct 2014 09:19:04 +0200
Received: by mail-yh0-f42.google.com with SMTP id t59so877249yho.29 for ; Tue, 21 Oct 2014 00:19:02 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.110.35 with SMTP id t23mr12338673yhg.126.1413875942407;  Tue, 21 Oct 2014 00:19:02 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Tue, 21 Oct 2014 00:19:02 -0700 (PDT)
In-Reply-To: 
References:   
Date: Tue, 21 Oct 2014 09:19:02 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1133358a4dc6160505e9a588
X-Provags-ID: V02:K0:SX8hH6DOp6floV40EaKFyJIZMY6nAb+JZNomFkJxbXs BbD7iqITmmt2eOXrIWuXfsqvL60dI74SFhLwCO042jiMSvGqwe JJHc8bR23ifL4oCMeDX+8PvkSlsjLmZw/wm+mEIfCVHIC51hyu 7KTUZAfQMZTi84BriLdO5Us+32Ecl9iFhykiKh1oj2e0RgfV2J WZ6F8eCESZjqv9q/vzDb6H/bGP6i4rrzkB+BYFkbfaAUHCuYMi RNabCrLqZtVZVUtBIF/aupvV98nsqfVr5CqPmOEAmKbVLVldRF WwBJdLBlf134ZQZw6E05Ypv9VSgPwDfvKFjJwTqRXVrgDGsJ4Z JqeNEoJeFayfqoJGv9MCsZ+45YW9CgvcvkNCeWLPsxks0T0wwc iNzprh0Kx/JSS0di/qUNIwqP37nYbGU3rMVw1mfLfqdw3gEJU7 ixsKQ
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d8G0VaviRpVIw64Tye2LIAmVhSY
Subject: Re: [TLS] POODLE applicability to TLS 1.0+ (was Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 07:19:08 -0000

--001a1133358a4dc6160505e9a588
Content-Type: text/plain; charset=UTF-8

Brian Smith :

My main concern is that we do not know how many TLS 1.0 servers actually
> check the padding, but we've assumed that all of them do, even though TLS
> 1.0 does not require checking the padding.


While the spec could be better, it clearly does expect implementation to
check the padding. (The alternative reading, as far as I can see, would be
that checking the MAC isn't required either.)



> For strong protection against bugs in old protocol versions, the only
>> option is to disallow those versions completely.
>>
>

> Yes, but TLS 1.0 implementations can mitigate the risk, as most do, by
> checking the padding conforms to the TLS 1.0 requirements.
>
> And, so can SSL 3.0 implementations, right? Checking that SSL 3.0 CBC-mode
> records conform to the TLS 1.0 padding rules is likely to cause some
> interop problems, but those interop problems would be much less severe than
> disabling SSL 3.0 completely, right?
>

Some implementations do indeed use TLS 1.0-style padding with SSL 3.0, but
not all do, and SSL 3.0 has too many other problems to be worth keeping
alive.

Bodo

--001a1133358a4dc6160505e9a588
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Bria=
n Smith <brian@briansmith.org>:

My main concern is that we do not know how many=
 TLS 1.0 servers actually check the padding, but we've assumed that all=
 of them do, even though TLS 1.0 does not require checking the padding.

While the spec could be better, it clearly doe=
s expect implementation to check the padding. (The alternative reading, as =
far as I can see, would be that checking the MAC isn't required either.=
)

=C2=A0
<=
/div>
For strong protection against bugs in old protocol v=
ersions, the only option is to disallow those versions completely.
=C2=
=A0
Yes, but TLS 1.0 implementations can mitigate th=
e risk, as most do, by checking the padding conforms to the TLS 1.0 require=
ments.=C2=A0

And, so can SSL 3.0 implementations, =
right? Checking that SSL 3.0 CBC-mode records conform to the TLS 1.0 paddin=
g rules is likely to cause some interop problems, but those interop problem=
s would be much less severe than disabling SSL 3.0 completely, right?
=


Some implementations do =
indeed use TLS 1.0-style padding with SSL 3.0, but not all do, and SSL 3.0 =
has too many other problems to be worth keeping alive.

=

Bodo



--001a1133358a4dc6160505e9a588--


From nobody Tue Oct 21 00:27:42 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48501AD08F for ; Tue, 21 Oct 2014 00:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5EEJkYouZY1 for ; Tue, 21 Oct 2014 00:27:37 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640071AD069 for ; Tue, 21 Oct 2014 00:27:37 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id hz20so474412lab.25 for ; Tue, 21 Oct 2014 00:27:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AWQyd4Z/t+5UiIZbjDqFP4TJmmosk+nzAOeNwFidNQs=; b=vmMkougDWIxtAFpwxQUBH6lHiCDnPjkKyiPUTox2781YPrZX1XRq+99ezujQsd9hNB me7NWBFIrynm91Ul2sLywYqWzrYE1G6sF73NcO4pjQejlT/7gewszZSFjH7gudvINdnu OQET9cGHK0qAdZpQt8YhPaakk2dBX7ZxkvvSMIqavLOrlF4hkSH5js1cNTAEs17qfLgC 7SUtfpBrwS2ZiEoMEIT1c/sy4Pcc+5ypOZTj6laxpv4Zb4BKr/bXiqEWWWyuWgI0gU4C LbnQBCeVvbqqygDTIZXp7f9VuKCEtUujNgXSu9VL+GHEX34nnVmAqEdHdarR9Ua2oyNO uf2A==
MIME-Version: 1.0
X-Received: by 10.112.94.133 with SMTP id dc5mr32531857lbb.11.1413876455747; Tue, 21 Oct 2014 00:27:35 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Tue, 21 Oct 2014 00:27:35 -0700 (PDT)
In-Reply-To: <544606E5.2070807@fussenegger.info>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org> <544606E5.2070807@fussenegger.info>
Date: Tue, 21 Oct 2014 00:27:35 -0700
Message-ID: 
From: Martin Thomson 
To: "Richard Fussenegger, BSc" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SbZrvcFGXy_TO-7t5F0SWqZacJw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 07:27:40 -0000

On 21 October 2014 00:10, Richard Fussenegger, BSc
 wrote:
> The idea of using a key length of at least the 'highest supported
> ciphers'[*] sounds very good to me

There is no technical reason that you would want a minimum length on
the ticket.  If you are using stateful resumption, a ticket of "1" or
"2" is perfectly sufficient.


From nobody Tue Oct 21 01:07:14 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155381AD289 for ; Tue, 21 Oct 2014 01:07:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuoDJQsn31gr for ; Tue, 21 Oct 2014 01:06:57 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27341AD0C2 for ; Tue, 21 Oct 2014 01:05:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413878716; x=1445414716; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=+VoCBKuq9UtJ3XtYG9d0Z9eNqwJpGQ1rnI3v2BkEFqc=; b=O4k8iaOncXr6FLKPNIBV71X5PlUj5ibMT34lmZcuHBzRfIa9Ei7Q1df9 VoDWt1oK9GsloptyKlRp5yYDBsbz5afkHD6YJlaiZMxXA5jvTbryHE52c h5oET+Q9PD2GVqf0HYvBOb42yAKTkghPrr+be+VGPhI2/7xLW2LN4M81X 0=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="284700837"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Oct 2014 21:05:14 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 21:05:13 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] PSK in 1.3?
Thread-Index: Ac/tBb3VLRb4HCJXSvm+2qnGVPmAmg==
Date: Tue, 21 Oct 2014 08:05:13 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D471A@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FZP71-YaTiG-FuylsVZ0x-hULoQ
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 08:07:02 -0000

Manuel P=E9gouri=E9-Gonnard  writes:=0A=
=0A=
>In addition to what Watson said, it's generally a bad idea to roll one's o=
wn=0A=
>crypto protocol, it's too easy to get things wrong. Even with PSK, TLS bri=
ngs=0A=
>you important things: a record protocol, a way to derive session keys from=
 the=0A=
>long-term secret key, etc.=0A=
=0A=
I'm just reviewing a design right now for which there's been an argument pu=
t=0A=
forward that it's too complicated and you could roll your own protocol that=
=0A=
would be much simpler.  The implementers are using EAP-PSK, which is a wee =
bit=0A=
complex, but then it has exactly the benefits you cite, everything's well-=
=0A=
defined (although the lack of test vectors is annoying), you just grab the =
RFC=0A=
and code it up and you're done.  Sure, you could homebrew your own=0A=
application-specific protocol that's simpler, but then you'd end up with a=
=0A=
proprietary, non-vetted, nonstandard one-off custom job that nothing else o=
n=0A=
earth can talk to.  That may be fine if you're building an Arduino-controll=
ed=0A=
electronic cat-door for your home, but not if it's commercial SCADA gear=0A=
that's going to be deployed all over the world.=0A=
=0A=
We'll see how the discussion over this pans out...=0A=
=0A=
Peter.=


From nobody Tue Oct 21 01:18:26 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D83C1AD3B1 for ; Tue, 21 Oct 2014 01:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.502
X-Spam-Level: 
X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lWOtl56R4vq for ; Tue, 21 Oct 2014 01:17:40 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBA11AD0BA for ; Tue, 21 Oct 2014 01:10:57 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C495B@USMBX1.msg.corp.akamai.com>
References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> <20141004033546.GG13254@mournblade.imrryr.org> <20141002175446.6EB7B1AEA6@ld9781.wdf.sap.corp> <54B025040D4F68B1E49919B8@nifty-silver.us.oracle.com>  ,  <1413868526423.88894@microsoft.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C495B@USMBX1.msg.corp.akamai.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Alyssa Rowan 
Date: Tue, 21 Oct 2014 09:10:46 +0100
To: tls@ietf.org
Message-ID: <358BD1AE-8354-41EB-9E85-69741DF00F69@akr.io>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nlFvVtKalQIS0gDqRY0NL6dd9Sc
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 08:17:51 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 21 October 2014 06:58:23 BST, "Salz, Rich"  wrote:

>+1
>
>Kill RC4 or put our face on it and face the public embarrassment.

Strong +1. I couldn't be stronger here.

I think we have rough consensus to publish this draft as-is right now, despite a couple of vocal but wrong-headed objections. I don't think further discussion makes RC4 any more, or less, weak, but delay keeps people using it for longer and that is bad.

If this WG cannot even achieve rough consensus about turning off a weak 20-year-old piece-of-crap cipher everyone knows is bad and which many fear will soon be (according to some sources has already been) broken catastrophically and irretrievably, then we have a much deeper problem and this WG is going to look utterly ineffectual and useless - which would mean taking our security, and pushing it somewhere else which can deal with it.

If you're waiting for a catastrophic break to be published to disable a cipher when it's already a decade overdue and you've been warned it's weak, then sorry but you're a complete idiot, attackers have saved all your juicy ciphertexts for the promised day, and will just sit there looking back at your (and your customers') precious data.

Anyone is free to ignore an RFC: just remember Chris, we warned you RC4 was weak; we told you that you MUST NOT use it in the clearest possible language. If you want to ignore that, you're facing the music when a break is published. Keeping RC4 enabled is the kind of thing you should, and will, fail audits for.

Don't make me get the whips out! ;-)

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJURhUGGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6088P/imVPNrVpDrcyG0Gsl/5sMCqasrzSfDEG8ZJZNUNGQ3msCA1SzYr
XEx4FVHVX2/0fwrDftIU/N+1ECiV+l6PQf7Xoeh6XBr0P8gxMocb49J2rlZGhV9c
aZPfz40wktglMJYNlXoKu2GsoUTOaBY+DUiOygpB0nerix9k06FXcuu26y3eGyB+
bMlL2oxNvrpYJtbBNrPaRAKr1xee8AwaQzWkWoqeqjBJjwCKGp98SUS96jpXddp3
P55CDs15LsMP2dHJtkM6xS1OZWAHEZwG+3BSGJOgrkMD1hMstwNAFtJxTmOc/BRs
uFbUpYISxp1s+6ZZYH94e8Nzcr0mF6AYS3AjAXTZDGzl62LQajafxLVA13Bokoia
KHvvxylIvDNqSYu4nysJrjOX8rnrDk1m7dPZBG1Yj++4zJZ5KbxBUhzjYooX0yzp
IWIeveDOswD4n8oTKeRN3CnwYc25GLHhyg+jGrs5ullFNKwTh12G726XTd8FeGOO
AdMO0T23qhj2JpzOT2v8fd2+03FEWhkc24w/2BrdtfwZWOwN1CG9kaIMnkUzOefd
50Myy1Iws33P6tOm4X/v7vvtDLQo+aZbfHebkU4289j4D1e+e50QfWR+AYqhOOI7
dKkVMIiZALHTnlLFn9dMO2UIjlYffaugjQNBvppcqWviarYW4zi5cVNi
=t57m
-----END PGP SIGNATURE-----


From nobody Tue Oct 21 01:36:49 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FA41A006F for ; Tue, 21 Oct 2014 01:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPiH4jiKcKJZ for ; Tue, 21 Oct 2014 01:36:45 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17281AD0AF for ; Tue, 21 Oct 2014 01:21:39 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id mc6so567897lab.30 for ; Tue, 21 Oct 2014 01:21:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=WfNpQUxskJjH1ttiFPkpmgPBhtngZjz5Z8H+f/j1o3s=; b=dKMkZ17GiEA6+sLnHdx7bjrHI1YS1lW5HZsJFCv3dDhcS581pdeh6/SMEjpJhae/Wy G0Buw7J2RigEn6syYOTYJWLspVQv3QqEo8L+C9phB9OVohZCeyJY/6tqfc89VJjHvWTf OiggSdHlRK9sZvRiSn1YSPQamyFzkfP5uVmpUBso9XAJqd+p67G8rrjoiCPVqBTifwFN DQQpXSECCF7Qzrfjajyi7g2Nc1cGavGEGU1lrLkAezl8EIfJaV6ib7VXSO5jBHNvZCNq 2t8z9LilXe9pfUX3kbT+DUV0G0FT/V7gIUwfNBkiCcqWzGSC7c1Wi9BDmyz4civpPYkz DDHw==
MIME-Version: 1.0
X-Received: by 10.112.210.102 with SMTP id mt6mr15961009lbc.73.1413879698354;  Tue, 21 Oct 2014 01:21:38 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Tue, 21 Oct 2014 01:21:38 -0700 (PDT)
Date: Tue, 21 Oct 2014 01:21:38 -0700
Message-ID: 
From: Martin Thomson 
To: Bodo Moeller , "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/N4TsJfD7tETL6UqzBdOm17RfPsI
Subject: [TLS] Operational consideration for downgrade SCSV draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 08:36:48 -0000

As discussed, something like this might be good:

"Note: Upgrading servers to support this SCSV in a cluster containing
version intolerant nodes can result in excessive numbers of failures.
Clients that learn of version intolerance from the intolerant nodes
will cause upgraded nodes to generate inappropriate_fallback alerts."


From nobody Tue Oct 21 02:58:08 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2570C1A00A3 for ; Tue, 21 Oct 2014 02:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level: 
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqMUJRfgSGO3 for ; Tue, 21 Oct 2014 02:58:04 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2B01A0242 for ; Tue, 21 Oct 2014 02:58:03 -0700 (PDT)
Received: (qmail 12500 invoked by uid 1000); 21 Oct 2014 09:58:00 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 21 Oct 2014 10:58:00 +0100
Message-ID: <54462E27.30607@comodo.com>
Date: Tue, 21 Oct 2014 10:57:59 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Brian Smith ,  Martin Thomson 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com><5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com><2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com><543E9C9F.5050104@redhat.com><2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com><543E9FFA.5030102@redhat.com><543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org><543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org><1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com><1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kz7xfekvz_-ltBP157HUNWmkD6E
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call fordraft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 09:58:07 -0000

On 20/10/14 18:30, Brian Smith wrote:
> On Mon, Oct 20, 2014 at 4:53 AM, Martin Thomson wrote:

>     I think that we should do that, but as a practical matter, I suspect
>     that we'll be stuck with some amount of fallback for a while yet.  I
>     find the TLS 1.3 intolerance numbers pretty alarming in this regard;
>     even with rapid improvement, I doubt it will go away quickly.
>
> That's why the version negotiation mechanism for TLS 1.3 should be
> different. We've already made the mistake 3 times of trying to use
> ClientHello.client_version to negotiate versions and 3 times we've
> learned that it has terrible compatibility issues. Why keep repeating
> that same mistake? By negotiating TLS 1.3 with a new extension, and
> keeping ClientHello.client_version = TLS 1.2 for TLS 1.3, you avoid the
> compatibility costs without losing anything.

How about negotiating TLS 1.3 using yet another new SCSV?

Yes, I know, that'd be even more of a hack than negotiating TLS 1.3 with 
a new extension.  But since server-side support for extensions is 
optional, and since there are servers out there that are 
extension-intolerant, I figured I should at least suggest the idea.  ;-)

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From nobody Tue Oct 21 03:03:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDBF1A01BA for ; Tue, 21 Oct 2014 03:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wWOEOfHixKD for ; Tue, 21 Oct 2014 03:03:28 -0700 (PDT)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF6C1A01A8 for ; Tue, 21 Oct 2014 03:03:27 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 58D5E188765; Tue, 21 Oct 2014 13:03:24 +0300 (EEST)
Date: Tue, 21 Oct 2014 13:03:24 +0300
From: Ilari Liusvaara 
To: Rob Stradling 
Message-ID: <20141021100324.GA12704@LK-Perkele-VII>
References: <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>  <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com>   <54462E27.30607@comodo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <54462E27.30607@comodo.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lDej69vJcRj-Kx6rlLADGBAM5Pk
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call fordraft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 10:03:30 -0000

On Tue, Oct 21, 2014 at 10:57:59AM +0100, Rob Stradling wrote:
> 
> How about negotiating TLS 1.3 using yet another new SCSV?
> 
> Yes, I know, that'd be even more of a hack than negotiating TLS 1.3 with a
> new extension.  But since server-side support for extensions is optional,
> and since there are servers out there that are extension-intolerant, I
> figured I should at least suggest the idea.  ;-)

One needs extensions anyway in order to transport data required for
TLS 1.3 handshake (groups supported and key shares for subset of those).


-Ilari


From nobody Tue Oct 21 03:57:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F841A19EA for ; Tue, 21 Oct 2014 03:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M50sCTpcyZXs for ; Tue, 21 Oct 2014 03:57:40 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A1E1A19E2 for ; Tue, 21 Oct 2014 03:57:24 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id r20so1550039wiv.4 for ; Tue, 21 Oct 2014 03:57:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9M1tVeArqBKdnTjvygiMBGu3PWYvSn3HXrUjvJj3CIw=; b=KN5SfwRDBFkGS+0Uyz8C0GkdfQzzAVQM1wxLl9wxYpugrwGTf52ZQ0ypJ7wF5t8dLj koEZfbXcKN2S3o0Zj3AlIyB3rcZc0+3OxMZ7JIUGx1dxnTmhbQ1M18W6nS4UAbLj5yCG rQYpWj0EC9cxQmjreNvjoGpuqj4vCQAds/YRmwPo7y0xmwRYi329GCC7ZVjzc+ooCAs1 NdZo0PdumAi6sTzkH28/gDWRybm3yuguOWYZ6+bhLp2cpFQ7R41+lAYBARZx+nUrv0Fm GSJcS/dzU6mzlSM99jEhjcxszIOwy6MuAF/FUhZo8pzy1whJ3jAZeYpxEjwg9LdthVlo ChqA==
X-Received: by 10.180.207.77 with SMTP id lu13mr28714660wic.12.1413889038966;  Tue, 21 Oct 2014 03:57:18 -0700 (PDT)
Received: from [172.24.248.215] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id td9sm12713253wic.15.2014.10.21.03.57.17 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 03:57:18 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir 
In-Reply-To: <358BD1AE-8354-41EB-9E85-69741DF00F69@akr.io>
Date: Tue, 21 Oct 2014 13:57:13 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <74F5F716-A220-4C92-AD8C-1CB3A8AC55DC@gmail.com>
References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> <20141004033546.GG13254@mournblade.imrryr.org> <20141002175446.6EB7B1AEA6@ld9781.wdf.sap.corp> <54B025040D4F68B1E49919B8@nifty-silver.us.oracle.com>   <, >  <1413868526423.88894@microsoft.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C495B@USMBX1.msg.corp.akamai.com> <358BD1AE-8354-41EB-9E85-69741DF00F69@akr.io>
To: Alyssa Rowan 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YgkBVkVqOZbmkYzsaujRKu3J3uU
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 10:57:42 -0000

+1

Outright prohibit RC4. If someone still supports RC4, then they=E2=80=99re=
 not compliant with the RFC, nothing more, nothing less.

And if some auditors take it upon themselves to threaten administrators =
into removing support for RC4, then for once they=E2=80=99re doing =
something we can all get behind.

Yoav

> On Oct 21, 2014, at 11:10 AM, Alyssa Rowan  wrote:
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>=20
> On 21 October 2014 06:58:23 BST, "Salz, Rich"  =
wrote:
>=20
>> +1
>>=20
>> Kill RC4 or put our face on it and face the public embarrassment.
>=20
> Strong +1. I couldn't be stronger here.
>=20
> I think we have rough consensus to publish this draft as-is right now, =
despite a couple of vocal but wrong-headed objections. I don't think =
further discussion makes RC4 any more, or less, weak, but delay keeps =
people using it for longer and that is bad.
>=20
> If this WG cannot even achieve rough consensus about turning off a =
weak 20-year-old piece-of-crap cipher everyone knows is bad and which =
many fear will soon be (according to some sources has already been) =
broken catastrophically and irretrievably, then we have a much deeper =
problem and this WG is going to look utterly ineffectual and useless - =
which would mean taking our security, and pushing it somewhere else =
which can deal with it.
>=20
> If you're waiting for a catastrophic break to be published to disable =
a cipher when it's already a decade overdue and you've been warned it's =
weak, then sorry but you're a complete idiot, attackers have saved all =
your juicy ciphertexts for the promised day, and will just sit there =
looking back at your (and your customers') precious data.
>=20
> Anyone is free to ignore an RFC: just remember Chris, we warned you =
RC4 was weak; we told you that you MUST NOT use it in the clearest =
possible language. If you want to ignore that, you're facing the music =
when a break is published. Keeping RC4 enabled is the kind of thing you =
should, and will, fail audits for.
>=20
> Don't make me get the whips out! ;-)
>=20
> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.1.1
>=20
> iQI3BAEBCgAhBQJURhUGGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
> jtkWi2t6088P/imVPNrVpDrcyG0Gsl/5sMCqasrzSfDEG8ZJZNUNGQ3msCA1SzYr
> XEx4FVHVX2/0fwrDftIU/N+1ECiV+l6PQf7Xoeh6XBr0P8gxMocb49J2rlZGhV9c
> aZPfz40wktglMJYNlXoKu2GsoUTOaBY+DUiOygpB0nerix9k06FXcuu26y3eGyB+
> bMlL2oxNvrpYJtbBNrPaRAKr1xee8AwaQzWkWoqeqjBJjwCKGp98SUS96jpXddp3
> P55CDs15LsMP2dHJtkM6xS1OZWAHEZwG+3BSGJOgrkMD1hMstwNAFtJxTmOc/BRs
> uFbUpYISxp1s+6ZZYH94e8Nzcr0mF6AYS3AjAXTZDGzl62LQajafxLVA13Bokoia
> KHvvxylIvDNqSYu4nysJrjOX8rnrDk1m7dPZBG1Yj++4zJZ5KbxBUhzjYooX0yzp
> IWIeveDOswD4n8oTKeRN3CnwYc25GLHhyg+jGrs5ullFNKwTh12G726XTd8FeGOO
> AdMO0T23qhj2JpzOT2v8fd2+03FEWhkc24w/2BrdtfwZWOwN1CG9kaIMnkUzOefd
> 50Myy1Iws33P6tOm4X/v7vvtDLQo+aZbfHebkU4289j4D1e+e50QfWR+AYqhOOI7
> dKkVMIiZALHTnlLFn9dMO2UIjlYffaugjQNBvppcqWviarYW4zi5cVNi
> =3Dt57m
> -----END PGP SIGNATURE-----
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Tue Oct 21 04:00:55 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECDD1A0ABD for ; Tue, 21 Oct 2014 04:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBkNZmLFecFu for ; Tue, 21 Oct 2014 04:00:51 -0700 (PDT)
Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D119B1A19F9 for ; Tue, 21 Oct 2014 04:00:18 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id b13so1018502wgh.0 for ; Tue, 21 Oct 2014 04:00:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IVtpMaKyANX1+AsFnOhSMHJKFrrWVdx6rCipeEiMDjY=; b=xbmGi+uhZzPItmzHP3zQ4cY9yR42A7owd2r3nqCsWWNIOs+/znH1x3SvLw9Vdv7fPO 2VzfLdZbAV5EPnEUJTHxe3+lTb3kB5fdVe995s5aL7eUuwlGwCERA50poIlPSMBlt0lf 5wDjNe1V25qY03zlcaAJHlbZ1WfOykBRcmX5gZiPRfC6W2M4lLS7jq1d+5FfMNiZ4hWh R5swpy51bxD7MR0IPYfu2ATIy/Je9yLQOW83cHU+1/aPxP32KVXS6alAI0xJjzuGVDbB vQwyJwxA37LkG+RT82COTpnNhfQnTsnRLtz55EgN0d4BcgK0Hx/4q4eO0dKgdriib/by XBpg==
X-Received: by 10.181.13.201 with SMTP id fa9mr16675128wid.0.1413889209800; Tue, 21 Oct 2014 04:00:09 -0700 (PDT)
Received: from [172.24.248.215] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id cu9sm15011672wjc.3.2014.10.21.04.00.08 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 04:00:09 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir 
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9D471A@uxcn10-5.UoA.auckland.ac.nz>
Date: Tue, 21 Oct 2014 14:00:06 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <47FA7D4F-07BC-4C42-9038-94A367C6B1E1@gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D471A@uxcn10-5.UoA.auckland.ac.nz>
To: Peter Gutmann 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yv6ucr3ddF1olnIYMRkk_lTL0oY
Cc: "" 
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 11:00:53 -0000

> On Oct 21, 2014, at 11:05 AM, Peter Gutmann =
 wrote:
>=20
> Manuel P=E9gouri=E9-Gonnard  writes:
>=20
>> In addition to what Watson said, it's generally a bad idea to roll =
one's own
>> crypto protocol, it's too easy to get things wrong. Even with PSK, =
TLS brings
>> you important things: a record protocol, a way to derive session keys =
from the
>> long-term secret key, etc.
>=20
> I'm just reviewing a design right now for which there's been an =
argument put
> forward that it's too complicated and you could roll your own protocol =
that
> would be much simpler.  The implementers are using EAP-PSK, which is a =
wee bit
> complex, but then it has exactly the benefits you cite, everything's =
well-
> defined (although the lack of test vectors is annoying), you just grab =
the RFC
> and code it up and you're done.  Sure, you could homebrew your own
> application-specific protocol that's simpler, but then you'd end up =
with a
> proprietary, non-vetted, nonstandard one-off custom job that nothing =
else on
> earth can talk to.  That may be fine if you're building an =
Arduino-controlled
> electronic cat-door for your home, but not if it's commercial SCADA =
gear
> that's going to be deployed all over the world.
>=20
> We'll see how the discussion over this pans out...
>=20
> Peter.

Is that related to http://tools.ietf.org/html/draft-nir-tls-eap-13 ?

Yoav



From nobody Tue Oct 21 04:46:43 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30901A1AFA for ; Tue, 21 Oct 2014 04:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RCy1aH0Y5lp for ; Tue, 21 Oct 2014 04:46:39 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8021A1AF2 for ; Tue, 21 Oct 2014 04:46:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413891999; x=1445427999; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=jEsT1WDyD8yvGCzxkVzU9xyc7RXTa1kFoFt5bQN1858=; b=Y3qEFNjNKkjzE67tTVbL1kV4e+FgXSsNIlt3e3K0fR+oMkzC5mZ1ZUBo nGOkavxMKWUjNXAoQ3SXl6n17p+sQWGebV3sN3ET57GRM10pWgzi9oqDP KIcXamRlaBeHHVvShHglBvyxucUCO19TzjJVsfnAL8Y0k4OlpHhZ8krey c=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="284730858"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 22 Oct 2014 00:46:37 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 00:46:37 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] PSK in 1.3?
Thread-Index: Ac/tJKtA3Idvx/btRbOE5jAr1DXLNA==
Date: Tue, 21 Oct 2014 11:46:36 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D4948@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zSlj2EXmbS2cyr9lO-KfACGgGxA
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 11:46:42 -0000

Yoav Nir  writes:=0A=
=0A=
>Is that related to http://tools.ietf.org/html/draft-nir-tls-eap-13 ?=0A=
=0A=
No, it's for a device that has to run for several years off its built-in=0A=
battery, so it can't run anything that requires a lot of power ("a lot" mea=
ns=0A=
anything more than maybe a few hundred microamps when it wakes up every now=
=0A=
and then, I haven't looked at the datasheet yet).=0A=
=0A=
Peter.=0A=


From nobody Tue Oct 21 07:37:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2B21A700B for ; Tue, 21 Oct 2014 07:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVjGVa0ZPZJR for ; Tue, 21 Oct 2014 07:37:01 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07681A7003 for ; Tue, 21 Oct 2014 07:36:46 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 6E5AF6F49C; Tue, 21 Oct 2014 16:36:43 +0200 (CEST)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id D045640E6B; Tue, 21 Oct 2014 16:36:43 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C8FB11AEFE; Tue, 21 Oct 2014 16:36:43 +0200 (CEST)
In-Reply-To: <71017e66b8ea43dea1e708e41b6aa93f@BL2PR03MB419.namprd03.prod.outlook.com>
To: Andrei Popov 
Date: Tue, 21 Oct 2014 16:36:43 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141021143643.C8FB11AEFE@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cjKO5x1aYTqMLrcbNwmu7ozPgrQ
Cc: "" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 14:37:05 -0000

Andrei Popov wrote:
>
>> Oh, and given your affiliation, I was tempted to add:
>> "So Microsoft are planning to roll out an update to Windows XP then?" :-).
>
> Hopefully, POODLE will help bring about the end of XP :)

Windows XP, with MSIE 7 or MSIE 8 installed is *UNAFFECTED* by Poodle,
because it will offer TLSv1.0 and not fallback to SSLv3 only.

Win7 & Win8.x Users are affected by Poodle.


-Martin


From nobody Tue Oct 21 07:44:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44A11A6F45 for ; Tue, 21 Oct 2014 07:44:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 279ioI2GTqh7 for ; Tue, 21 Oct 2014 07:44:28 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 300F71A6F0B for ; Tue, 21 Oct 2014 07:44:28 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 83E65284EF for ; Tue, 21 Oct 2014 14:44:27 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 70FCB284EE for ; Tue, 21 Oct 2014 14:44:27 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 6C339202A for ; Tue, 21 Oct 2014 14:44:27 +0000 (GMT)
Received: from usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 21 Oct 2014 10:44:27 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Tue, 21 Oct 2014 10:44:26 -0400
From: "Salz, Rich" 
To: "TLS@ietf.org (tls@ietf.org)" 
Date: Tue, 21 Oct 2014 10:44:24 -0400
Thread-Topic: Minutes from Tuesday
Thread-Index: Ac/s/80MFVvbkl4TRbKNfELmt8XWcw==
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6@USMBX1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6USMBX1msgcorp_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vQ7yLwUd5OZanqC7lXjf4OvStcg
Subject: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 14:44:34 -0000

--_000_2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6USMBX1msgcorp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Here's the draft minutes for today's interim.  Please post corrections to t=
he list.

Should we remove SSLv3 from the session hash draft?  Various points about w=
hy SSLv3 is either not being used, or in devices that aren't being updated.=
 One more update to remove SSLv3, some other cleanups, and then go to WG LC=
. Sean will try to force out any issues for discussion in Hawaii.

Bodo slides are at https://github.com/tlswg/wg-materials/blob/master/201410=
21_interim/TLS_FALLBACK_SCSV_IETF_TLS_Interim_Oct_2014.pdf   Based on list =
feedback, going to add some clarifications (no changes to the mechanism).  =
False start I-D needs to be updated since attacker can force a version; Bod=
o to do that. Discussion of distinguishing between TCP reset (in FF) and ve=
rsion intolerance. Discussion of when to 'guess' failure is transient or ve=
rsion intolerance. Need to add some guidance to the I-D: mixing SCSV and ve=
rsion-intolerant servers will cause a pain. Sean went through issues raised=
 on mailing list.

What is status of false-start? Was held back by Google for interop concerns=
. MSFT always tries based on cipher-suite (says MT); others do it condition=
al on NPN or ALPN and a modern cipher like a DH. It's in wide use. Bodo wil=
l update the draft and ask the WG to adopt

Dkg on named groups. No longer an extension; allocating points within the n=
amedcurve list, they are finite-field groups. Interacts with cipher-suite l=
ist.  Discussion about adding ordering semantics between the two lists. Cha=
nge: clients that wish to express an ordering may order the curves/groups i=
n their order of preference.

Discussion of RC4 draft.  Andrei via phone. Room strongly supports prohibit=
ing RC4. Discussion about being able to address concerns raised by a few. C=
hair will close discussion and move it forward. Sean to include text about =
"just upgrade to TLS 1.2" as we considered alternatives and rejected them i=
n his shepard notes or equivalent. Mention that youtube encodes video strea=
ms using RC4 only.

Return to DH named groups.  Dkg prefers not-using IKEv2 primes, so that nat=
ional-scale adversaries workload doubles. We'll ask CFRG "do you have a pro=
blem with these groups?" Decided that SRP re-use of IKEv2 groups is not an =
issue. Discussion of sizes.  Sean going to straw poll the list for 2048 or =
2432, will work with dkg to draft the message. Proposed sizes 20xx 3032 409=
6 8192. Discussion of having server return the full key.  Dkg to come back =
to the mailing list. Discussion of how to do PSK with PFS; neat hack/though=
t, treat it like a resumption.

Compressed points. Certicom says no IPR coverage any more. Likely to drop u=
ncompressed points (and their negotiation) from TLS 1.3  ekr to do a straw =
poll on the mailing list.


--
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


--_000_2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6USMBX1msgcorp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Here’s the=
 draft minutes for today’s interim.  Please post corrections to =
the list.
 
Should we remove SSLv3 from the session hash draft?  Vari=
ous points about why SSLv3 is either not being used, or in devices that are=
n’t being updated. One more update to remove SSLv3, some other cleanu=
ps, and then go to WG LC. Sean will try to force out any issues for discuss=
ion in Hawaii.
 
Bodo slides are at https://github.com/tlswg/wg-materials/b=
lob/master/20141021_interim/TLS_FALLBACK_SCSV_IETF_TLS_Interim_Oct_2014.pdf=
   Based on list feedback, going to add some clarifications (no c=
hanges to the mechanism).  False start I-D needs to be updated since a=
ttacker can force a version; Bodo to do that. Discussion of distinguishing =
between TCP reset (in FF) and version intolerance. Discussion of when to &#=
8216;guess’ failure is transient or version intolerance. Need to add =
some guidance to the I-D: mixing SCSV and version-intolerant servers will c=
ause a pain. Sean went through issues raised on mailing list.
 
What is sta=
tus of false-start? Was held back by Google for interop concerns. MSFT alwa=
ys tries based on cipher-suite (says MT); others do it conditional on NPN o=
r ALPN and a modern cipher like a DH. It’s in wide use. Bodo will upd=
ate the draft and ask the WG to adopt 
<=
o:p> 
Dkg on named groups. No longer an =
extension; allocating points within the namedcurve list, they are finite-fi=
eld groups. Interacts with cipher-suite list.  Discussion about adding=
 ordering semantics between the two lists. Change: clients that wish to exp=
ress an ordering may order the curves/groups in their order of preference.<=
o:p>
 
Discussion of RC4 draft.  Andrei via phone. Room strongly supports p=
rohibiting RC4. Discussion about being able to address concerns raised by a=
 few. Chair will close discussion and move it forward. Sean to include text=
 about “just upgrade to TLS 1.2” as we considered alternatives =
and rejected them in his shepard notes or equivalent. Mention that youtube =
encodes video streams using RC4 only.
 
Return to DH named groups.  Dk=
g prefers not-using IKEv2 primes, so that national-scale adversaries worklo=
ad doubles. We’ll ask CFRG “do you have a problem with these gr=
oups?” Decided that SRP re-use of IKEv2 groups is not an issue. Discu=
ssion of sizes.  Sean going to straw poll the list for 2048 or 2432, w=
ill work with dkg to draft the message. Proposed sizes 20xx 3032 4096 8192.=
 Discussion of having server return the full key.  Dkg to come back to=
 the mailing list. Discussion of how to do PSK with PFS; neat hack/thought,=
 treat it like a resumption.
 =

Compressed points. Certicom says no IPR cove=
rage any more. Likely to drop uncompressed points (and their negotiation) f=
rom TLS 1.3  ekr to do a straw poll on the mailing list.
 
 
 
-- =
; 
Principal Security Engineer, Akamai T=
echnologies
IM: rsalz@jabber.me Twitter: RichSalz
 
=

--_000_2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6USMBX1msgcorp_--


From nobody Tue Oct 21 07:53:20 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5191A6F6D for ; Tue, 21 Oct 2014 07:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GfYZUMX7jN6 for ; Tue, 21 Oct 2014 07:53:13 -0700 (PDT)
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB211A6F7F for ; Tue, 21 Oct 2014 07:53:12 -0700 (PDT)
Received: by mail-wg0-f46.google.com with SMTP id l18so1602343wgh.29 for ; Tue, 21 Oct 2014 07:53:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=t0pbSMFGH0T9x2ysRFsgDux+OFI99Ow8EWAWIALN8ds=; b=E6JTVQPfAxTBk/tACTix30F2FW57MTrL2NqSiaugoeeDQ89bA2HRj8XI9raOHNOAdO qvG1xy82STZqEKOmzUhWBXPboR/5URW5Fmp6+7OrsVvWY1RKDu/329+4y6tVkCJGBN++ 5on5BSbVuZ02rIUOxUoWosGhV/HEJZzCuN6KX08Ek9LuUIVH6Ae9HyC1cC93DanCYXTN q+bMemrfJHzW18Xic14QhdNmttnBsfElInowOEl5HcZLCIDliLKi9e3Yt2T20A30oZYw XUlc6VknxqwBx3ESadO1pKgMBWCOnFWqygUpbcgPxTDWS+yWvO08KvadQXbirdEovHcw LkuA==
X-Gm-Message-State: ALoCoQmGi/fTrSwMlkDTsqIsaHwgVtAa2o2qdPQ+UxqJcvyFpcbmXt83ZPTjF4QjLJeiaPuKaQ6J
X-Received: by 10.194.79.201 with SMTP id l9mr43631678wjx.59.1413903189833; Tue, 21 Oct 2014 07:53:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Tue, 21 Oct 2014 07:52:29 -0700 (PDT)
From: Eric Rescorla 
Date: Tue, 21 Oct 2014 16:52:29 +0200
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7bf0d0f660b0730505effd80
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Zan7ox1paKGq1RUovxelkQlcvI0
Subject: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 14:53:16 -0000

--047d7bf0d0f660b0730505effd80
Content-Type: text/plain; charset=UTF-8

https://github.com/tlswg/tls13-spec/issues/80

Today we discussed the possibility of requiring support for compressed
points
in TLS 1.3 now that the IPR has expired.

Specifically, I propose that for TLS 1.3, we:

- Use only compressed points for the existing curves (and presumably
  whatever superior format is defined for the CFRG-recommended
  curves, as appropriate).

- Deprecate the Supported Point Formats extension for TLS 1.3


For RFC 4492-bis, we might also consider requiring support for compressed
points as well as uncompressed (already required) but this seems like a
separable issue, since it's mostly in service of optimization rather than
simplicity.

What do people think?
-Ekr

--047d7bf0d0f660b0730505effd80
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


=
https://github.com/tlswg/tls13-spec/issues/80

Today =
we discussed the possibility of requiring support for compressed points
in TLS 1.3 now that the IPR has expired.

Sp=
ecifically, I propose that for TLS 1.3, we:

- Use =
only compressed points for the existing curves (and presumably
=
=C2=A0 whatever superior format is defined for the CFRG-recommended
=C2=A0 curves, as appropriate).

- Deprecate the=
 Supported Point Formats extension for TLS 1.3

For RFC 4492-bis, we might also consider requiring support for =
compressed
points as well as uncompressed (already required) but =
this seems like a
separable issue, since it's mostly in servi=
ce of optimization rather than
simplicity.

What do people think?
-Ekr


=






--047d7bf0d0f660b0730505effd80--


From nobody Tue Oct 21 08:01:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C981A8734 for ; Tue, 21 Oct 2014 08:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level: 
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41IejgBnkJxq for ; Tue, 21 Oct 2014 08:01:12 -0700 (PDT)
Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A031A872A for ; Tue, 21 Oct 2014 08:01:11 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9LF1BhV030752; Tue, 21 Oct 2014 11:01:11 -0400
Date: Tue, 21 Oct 2014 11:01:11 -0400 (EDT)
From: Hubert Kario 
To: Eric Rescorla 
Message-ID: <2108842737.16216761.1413903671102.JavaMail.zimbra@redhat.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_16216760_118954521.1413903671101"
X-Originating-IP: [10.5.82.6]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF33 (Linux)/8.0.6_GA_5922)
Thread-Topic: Should we require compressed points
Thread-Index: s81vKVssHJWrVdc58iVogbrEdyitYg==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FMjoHXoKE45hopk0qIflaWfFHkU
Cc: tls@ietf.org
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 15:01:19 -0000

------=_Part_16216760_118954521.1413903671101
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

----- Original Message -----

> From: "Eric Rescorla" 
> To: tls@ietf.org
> Sent: Tuesday, 21 October, 2014 4:52:29 PM
> Subject: [TLS] Should we require compressed points

> https://github.com/tlswg/tls13-spec/issues/80

> Today we discussed the possibility of requiring support for compressed points
> in TLS 1.3 now that the IPR has expired.

> Specifically, I propose that for TLS 1.3, we:

> - Use only compressed points for the existing curves (and presumably
> whatever superior format is defined for the CFRG-recommended
> curves, as appropriate).

> - Deprecate the Supported Point Formats extension for TLS 1.3

> For RFC 4492-bis, we might also consider requiring support for compressed
> points as well as uncompressed (already required) but this seems like a
> separable issue, since it's mostly in service of optimization rather than
> simplicity.

How does that impact possibility of adding more "exotic" curves like curve25519/Ed25519 
in some later point in time? 
-- 
Regards, 
Hubert Kario 

------=_Part_16216760_118954521.1413903671101
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


From: "Eric Rescorla" <ekr=
@rtfm.com>
To: tls@ietf.org
Sent: Tuesday, 21 Octobe=
r, 2014 4:52:29 PM
Subject: [TLS] Should we require compressed po=
ints



------=_Part_16216760_118954521.1413903671101--


From nobody Tue Oct 21 08:03:28 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72E31A870A for ; Tue, 21 Oct 2014 08:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id om0AjHOv-816 for ; Tue, 21 Oct 2014 08:03:24 -0700 (PDT)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1620A1A6EFF for ; Tue, 21 Oct 2014 08:03:23 -0700 (PDT)
Received: by mail-lb0-f175.google.com with SMTP id u10so1177571lbd.20 for ; Tue, 21 Oct 2014 08:03:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QXXBuiOGDGMyNAmA6JsUVwO981T9PbgY06RPfbc/5Po=; b=VP5Pfgsw/XTsHDjzx25Fb0knQnIyc/EZr9B+wsA9G4YhZORBU3VMfsfYtPjlQq2JJa WujXNpegB6t0lPbzYOQKc/4AEYTMiqEajMybgF+0cZgl97jblka6odHvktibjGmCqGWY /GB8FeXcuxRZ6+BDxC8cLDOW9y/Dx6AURPhYkuJU5vkiBtgLcGq6h35TwwvHfeguJTyu Tyzr2w5Ax5dHdWuT41Z73c+Jf/65aL7ghLv7gwAwEw9jUc4Q1v+3u0qwMgnF9eQ2Xv7Z WSBSj773b80Ds34TEkVtE3eDYxwEVkqpdFBbUbaKKCTBz4y6oClY/dlpFAGpR9A0YWgD q7sQ==
MIME-Version: 1.0
X-Received: by 10.152.27.38 with SMTP id q6mr4043839lag.92.1413903802245; Tue, 21 Oct 2014 08:03:22 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Tue, 21 Oct 2014 08:03:22 -0700 (PDT)
In-Reply-To: <2108842737.16216761.1413903671102.JavaMail.zimbra@redhat.com>
References:  <2108842737.16216761.1413903671102.JavaMail.zimbra@redhat.com>
Date: Tue, 21 Oct 2014 08:03:22 -0700
Message-ID: 
From: Martin Thomson 
To: Hubert Kario 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nBcozy6hq7JvRcqEeuX1JEXm9RU
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 15:03:26 -0000

On 21 October 2014 08:01, Hubert Kario  wrote:
> How does that impact possibility of adding more "exotic" curves like
> curve25519/Ed25519
> in some later point in time?

I'd have thought that this only applies to the existing registrations.
New registrations can define a proprietary format.


From nobody Tue Oct 21 08:04:18 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2724E1A870A for ; Tue, 21 Oct 2014 08:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WBLqLQMQfDv for ; Tue, 21 Oct 2014 08:04:12 -0700 (PDT)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0141A6EFF for ; Tue, 21 Oct 2014 08:04:11 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id m15so1594331wgh.28 for ; Tue, 21 Oct 2014 08:04:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4DwbB7J+6N25Z4llWrQX98yhrQ+77rJqHEHES4ZKWpQ=; b=I5R6h7Ov9iaHb8V2nSbtEYKULz+L4nO2vSf5G9O70aJSZemS+K0xzxiHv7juzJgQcM ZgXfIPtD2oipVsjq+kWpq9X5T+5A2o1LLvZT8tRfNsy0G5kQL90S2p2aDd4v8tqzAOtW el+4VsfX/TkXTKZ0toAmyNAwt1GB+edxT9UKG9YX3pozYDtTycGsqcdA19goqUmDLJPp SUyw8FIrjlZSCo9NV9O/c9vuuJg/E/JL3Qt+qh8kIZpd3kwNI4B7H9toQn//FJByRJsp wucBDIT1Zx57zD5G8mT6T6JD1gWzR98argWSRV6iy/NLFmq1CfJ7IyJGpPJe9DEi/V/P 5eTQ==
X-Gm-Message-State: ALoCoQm2ptuwtMN3Irqmvdd9jMunrXaQnXhsxK4bHmaCEcqFsihXC2v0xLePbKR8n0DJIPgDgyuL
X-Received: by 10.180.103.233 with SMTP id fz9mr29286924wib.80.1413903848165;  Tue, 21 Oct 2014 08:04:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Tue, 21 Oct 2014 08:03:27 -0700 (PDT)
In-Reply-To: <2108842737.16216761.1413903671102.JavaMail.zimbra@redhat.com>
References:  <2108842737.16216761.1413903671102.JavaMail.zimbra@redhat.com>
From: Eric Rescorla 
Date: Tue, 21 Oct 2014 17:03:27 +0200
Message-ID: 
To: Hubert Kario 
Content-Type: multipart/alternative; boundary=f46d044280ca9e0a4a0505f024b3
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HCSvScYEGrUIPhlaNH4WXO43cAo
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 15:04:15 -0000

--f46d044280ca9e0a4a0505f024b3
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 21, 2014 at 5:01 PM, Hubert Kario  wrote:

> ------------------------------
>
> *From: *"Eric Rescorla" 
> *To: *tls@ietf.org
> *Sent: *Tuesday, 21 October, 2014 4:52:29 PM
> *Subject: *[TLS] Should we require compressed points
>
>
> https://github.com/tlswg/tls13-spec/issues/80
>
> Today we discussed the possibility of requiring support for compressed
> points
> in TLS 1.3 now that the IPR has expired.
>
> Specifically, I propose that for TLS 1.3, we:
>
> - Use only compressed points for the existing curves (and presumably
>   whatever superior format is defined for the CFRG-recommended
>   curves, as appropriate).
>
> - Deprecate the Supported Point Formats extension for TLS 1.3
>
>
> For RFC 4492-bis, we might also consider requiring support for compressed
> points as well as uncompressed (already required) but this seems like a
> separable issue, since it's mostly in service of optimization rather than
> simplicity.
>
>
> How does that impact possibility of adding more "exotic" curves like
> curve25519/Ed25519
> in some later point in time?
>

Hubert, thanks for your email.

I don't think it should impact it at all because you still have to
advertise the curves you
support. My assumption is that advertising curve X would be the same as
advertising
that you could support its defined point format(s).

-Ekr

--f46d044280ca9e0a4a0505f024b3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Tue, Oct 21, 2014 at 5:01 PM, Hubert Kario <hkario@redhat.com> wrote:
<=
blockquote style=3D"border-left:2px solid #1010ff;margin-left:5px;padding-l=
eft:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:non=
e;font-family:Helvetica,Arial,sans-serif;font-size:12pt">From: "=
;Eric Rescorla" <=
ekr@rtfm.com>
To: tls@ietf.org
Sent: Tuesday, 21 October, 2014 4:52=
:29 PM
Subject: [TLS] Should we require compressed points


https://github.com/tlswg/tls13-spec=
/issues/80

Today we discussed the possibility of req=
uiring support for compressed points
in TLS 1.3 now that the IPR =
has expired.

Specifically, I propose that for TLS =
1.3, we:

- Use only compressed points for the exis=
ting curves (and presumably
=C2=A0 whatever superior format is de=
fined for the CFRG-recommended
=C2=A0 curves, as appropriate).

- Deprecate the Supported Point Formats extension fo=
r TLS 1.3


For RFC 4492-bis, we migh=
t also consider requiring support for compressed
points as well a=
s uncompressed (already required) but this seems like a
separable=
 issue, since it's mostly in service of optimization rather than
<=
div>simplicity.

How=
 does that impact possibility of adding more "exotic" curves like=
 curve25519/Ed25519
in some later point in time?

Hubert, thanks for your email.
=

I don't think it should impact it at all because you sti=
ll have to advertise the curves you
support. My assumption is tha=
t advertising curve X would be the same as advertising
that you c=
ould support its defined point format(s).

-Ekr





--f46d044280ca9e0a4a0505f024b3--


From nobody Tue Oct 21 08:06:00 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB2F1A8740 for ; Tue, 21 Oct 2014 08:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ic-7NbE1Cehl for ; Tue, 21 Oct 2014 08:05:39 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89EC81A873F for ; Tue, 21 Oct 2014 08:05:39 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 116B254D01; Tue, 21 Oct 2014 17:05:36 +0200 (CEST)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id E163A41728; Tue, 21 Oct 2014 17:05:36 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id DA17C1AEFE; Tue, 21 Oct 2014 17:05:36 +0200 (CEST)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6@USMBX1.msg.corp.akamai.com>
To: "Salz, Rich" 
Date: Tue, 21 Oct 2014 17:05:36 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141021150536.DA17C1AEFE@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9w6WQ5TKZbKfoq6gM0DLETHjaHo
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 15:05:45 -0000

Salz, Rich wrote:
> 
> Bodo slides are at https://github.com/tlswg/wg-materials/blob/master/20141021_interim/TLS_FALLBACK_SCSV_IETF_TLS_Interim_Oct_2014.pdf   Based on list feedback, going to add some clarifications (no changes to the mechanism).  False start I-D needs to be updated since attacker can force a version; Bodo to do that. Discussion of distinguishing between TCP reset (in FF) and version intolerance. Discussion of when to 'guess' failure is transient or version intolerance. Need to add some guidance to the I-D: mixing SCSV and version-intolerant servers will cause a pain. Sean went through issues raised on mailing list.

The current fallback-scsv is embarrassing.

Rather than aborthing the TLS handshake, the server ought to include
a TLS extension in the ServerHello indicating that he recognized a
potentially inappropriate fallback and otherwise continue the TLS handshake
in the regular fashion, leaving the decision of whether&how to continue
entirely up to those clients who do perform insecure fallbacks.

This would also allow clients (browsers probably) to gather real data
on potentially incorrect fallbacks, rather than have users face random
connection failures.  Connection failures for singular object may
appear easy to identify, but if it affects only small objects within
complex pages, the underlying cause of problems may be hard to identify.

And it would then be a decision of the (fallback-performing) clients
whether and when to start hard-failing, once they've sorted out their
connection management and figured out how to deal with false positives
in their fallback heuristics.

-Martin


From nobody Tue Oct 21 08:13:08 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329361A8722 for ; Tue, 21 Oct 2014 08:13:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBT1ULIFZX4h for ; Tue, 21 Oct 2014 08:12:59 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2793E1A8778 for ; Tue, 21 Oct 2014 08:11:18 -0700 (PDT)
Received: by mail-qa0-f44.google.com with SMTP id x12so961871qac.31 for ; Tue, 21 Oct 2014 08:11:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=Fr0p4KxZTrsmqy+H6U17hP2CsvmBgkpCznt+2e66buM=; b=BCciIFq4u4v2kBJzypNe43BU8YJTS36wiwu0PjrxFklizRmk/HKuqCxVcnypyVj9k4 OgLKe93uxdzXHOFJL65ldoO9xxg33PRZZy0OO5517RSXI+NHF+DaTGUaxdRdjP41HpnN 9eUGCmxN7oOY/gPR+oN2WnSjOCb925gpySTdAz1sgZ4jhYFPb28KRawAP1M92SYEWh6m GMKCMjaYxx9IsWYvQ9IFonFfsgJNQE1qZPuX7lE7rr/QXu5H6W+UdgVPdl6usYjFh2g7 s4RLwanIdMyLiMf4ObLVPwTKWUN6hnPk1oI0LuiunDtyJEQ5wR9W9D64h0lYtmQo++dg makA==
X-Gm-Message-State: ALoCoQn/ECkXIce07mUmjOvl2bbDws67lCWE/9MGdFM4ur7GjR4jdVZPs7EYYHrKOSOnZTZpZWrZ
X-Received: by 10.140.109.53 with SMTP id k50mr44580258qgf.83.1413904275647; Tue, 21 Oct 2014 08:11:15 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:e7:95c6:bde0:689a:9257? ([2601:a:2a00:e7:95c6:bde0:689a:9257]) by mx.google.com with ESMTPSA id g94sm10916130qgd.0.2014.10.21.08.11.15 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Oct 2014 08:11:15 -0700 (PDT)
Message-ID: <544677AE.4000005@nthpermutation.com>
Date: Tue, 21 Oct 2014 11:11:42 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080205020208050708060106"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ze4HYryr9JThxqmcunMZcN29jDU
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 15:13:02 -0000

This is a multi-part message in MIME format.
--------------080205020208050708060106
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 10/21/2014 10:52 AM, Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/issues/80
>
> Today we discussed the possibility of requiring support for compressed 
> points
> in TLS 1.3 now that the IPR has expired.
>
> Specifically, I propose that for TLS 1.3, we:
>
> - Use only compressed points for the existing curves (and presumably
>   whatever superior format is defined for the CFRG-recommended
>   curves, as appropriate).
>
> - Deprecate the Supported Point Formats extension for TLS 1.3

I'm pretty much opposed to the former and I guess by extension the latter.

There's a very large body of code that doesn't support anything except 
type 0x04(uncompressed) X9.63 point encodings.   If you want to add 
support for compressed points (or hybrid compressed), I don't think 
that's necessarily a bad idea, but not at the expense of removing 
support for uncompressed points.   If you wanted to remove the supported 
point format extension, I guess you could mandate support for both 
compressed and uncompressed (and hybrid?).

As a second item, I would estimate the  chance we're going to see 
compressed points in X509 certificates as a regular thing prior to about 
10 years from now as very small, meaning that any general transition to 
EC based suites is going to require uncompressed point support.

Lastly, while the base IPR for point compression seems to be no longer 
of concern, I've still been told to avoid it for a few more years due to 
implementation patents related to compression.  I'm not sure how 
worrisome that is, but its one of the reasons that binary curves aren't 
in broader use still.

Just my $.02

Mike

>
>
> For RFC 4492-bis, we might also consider requiring support for compressed
> points as well as uncompressed (already required) but this seems like a
> separable issue, since it's mostly in service of optimization rather than
> simplicity.
>
> What do people think?
> -Ekr
>
>
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--------------080205020208050708060106
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/21/2014 10:52 AM, Eric Rescorla
      wrote:

    

    

      
https://github.com/tlswg/tls13-spec/issues/80
        


        

        
Today we discussed the possibility of requiring support for
          compressed points

        
in TLS 1.3 now that the IPR has expired.

        


        

        
Specifically, I propose that for TLS 1.3, we:

        


        

        
- Use only compressed points for the existing curves (and
          presumably

        
  whatever superior format is defined for the
          CFRG-recommended

        
  curves, as appropriate).

        


        

        
- Deprecate the Supported Point Formats extension for TLS
          1.3

      

    

    

    I'm pretty much opposed to the former and I guess by extension the
    latter.

    

    There's a very large body of code that doesn't support anything
    except type 0x04(uncompressed) X9.63 point encodings.   If you want
    to add support for compressed points (or hybrid compressed), I don't
    think that's necessarily a bad idea, but not at the expense of
    removing support for uncompressed points.   If you wanted to remove
    the supported point format extension, I guess you could mandate
    support for both compressed and uncompressed (and hybrid?).

    

    As a second item, I would estimate the  chance we're going to see
    compressed points in X509 certificates as a regular thing prior to
    about 10 years from now as very small, meaning that any general
    transition to EC based suites is going to require uncompressed point
    support.

    

    Lastly, while the base IPR for point compression seems to be no
    longer of concern, I've still been told to avoid it for a few more
    years due to implementation patents related to compression.  I'm not
    sure how worrisome that is, but its one of the reasons that binary
    curves aren't in broader use still.

    

    Just my $.02

    

    Mike

    

    

      

        


        

        


        

        
For RFC 4492-bis, we might also consider requiring support
          for compressed

        
points as well as uncompressed (already required) but this
          seems like a

        
separable issue, since it's mostly in service of
          optimization rather than

        
simplicity.

        


        

        
What do people think?

        
-Ekr

        


        

        


        

        


        

        


        

        


        

      

      

      

      

      
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


    

    

  


--------------080205020208050708060106--


From nobody Tue Oct 21 08:16:40 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4360C1A8731 for ; Tue, 21 Oct 2014 08:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSIPamDdujgT for ; Tue, 21 Oct 2014 08:16:36 -0700 (PDT)
Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29581A872A for ; Tue, 21 Oct 2014 08:16:35 -0700 (PDT)
Received: by mail-qc0-f170.google.com with SMTP id m20so1109274qcx.29 for ; Tue, 21 Oct 2014 08:16:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=thF97ogD3E5PFpQhvoqp20iJ55H+NMznkHlfT3o2sOo=; b=ZPBO5ChbLeEBPibJKRO0TacVi1v+Uum7EqFnJqJZfdlYHBVsFJvde+mH9HVbha6eqe OIv0+kvMKMAt/JPnUL+YkMd7L4IzMIYpSMSO0tDJvM6My5Z4P/QmAiIuwSU8xpm27RIz FQvt+FPghETEfKbi6++WD2ylT2tTg+mUYHVJ1rPUWZT/xEZc1IcOw2KsqIODCM5Ti2U7 GHfLHaSILOk6vg0wfoO6T+kOHtl0/8YlRX6yO4yiqgAr1vyMCqyzmUo9VTvHwzzkEIe2 3BwbZrkgg/+65TFYNpzXV+DgzXx7cj6AIvytjDGS+gsxE8CehjeKI2O8K+ZodIaCaSeA hbvA==
X-Gm-Message-State: ALoCoQn3+G+1BY1ej8gW4rG1ukt4Er7C3KrPQHELekMYLhlrjx/Yflu3ltVslfISqjDThZ08bv+S
X-Received: by 10.224.79.211 with SMTP id q19mr14625596qak.101.1413904591783;  Tue, 21 Oct 2014 08:16:31 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:e7:95c6:bde0:689a:9257? ([2601:a:2a00:e7:95c6:bde0:689a:9257]) by mx.google.com with ESMTPSA id a10sm10937811qam.7.2014.10.21.08.16.31 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Oct 2014 08:16:31 -0700 (PDT)
Message-ID: <544678E8.4080708@nthpermutation.com>
Date: Tue, 21 Oct 2014 11:16:56 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References:  <2108842737.16216761.1413903671102.JavaMail.zimbra@redhat.com>
In-Reply-To: <2108842737.16216761.1413903671102.JavaMail.zimbra@redhat.com>
Content-Type: multipart/alternative; boundary="------------050804010503050206090102"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iaO6Bp7JZKVpbA2-52fsHsifqpU
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 15:16:38 -0000

This is a multi-part message in MIME format.
--------------050804010503050206090102
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 10/21/2014 11:01 AM, Hubert Kario wrote:
> ------------------------------------------------------------------------
>
>     *From: *"Eric Rescorla" 
>     *To: *tls@ietf.org
>     *Sent: *Tuesday, 21 October, 2014 4:52:29 PM
>     *Subject: *[TLS] Should we require compressed points
>
>     https://github.com/tlswg/tls13-spec/issues/80
>
>     Today we discussed the possibility of requiring support for
>     compressed points
>     in TLS 1.3 now that the IPR has expired.
>
>     Specifically, I propose that for TLS 1.3, we:
>
>     - Use only compressed points for the existing curves (and presumably
>       whatever superior format is defined for the CFRG-recommended
>       curves, as appropriate).
>
>     - Deprecate the Supported Point Formats extension for TLS 1.3
>
>
>     For RFC 4492-bis, we might also consider requiring support for
>     compressed
>     points as well as uncompressed (already required) but this seems
>     like a
>     separable issue, since it's mostly in service of optimization
>     rather than
>     simplicity.
>
>
> How does that impact possibility of adding more "exotic" curves like 
> curve25519/Ed25519
> in some later point in time?

My personal opinion is that there needs to be a complete separation in 
encodings and code points between X9.63 compliant EC data and anything 
else.

In the specific case of the curves you mention, unlike X9.63 curves, 
signing curves/keys and key agreement curves/keys are not 
interchangeable or compatible.  They are actually two different crypto 
systems and will probably require different code points  and maybe 
encodings.

The other classes of curves that don't have an X9.63 (Montgomery?) 
representation will need similar treatment.

Mike

> -- 
> Regards,
> Hubert Kario
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--------------050804010503050206090102
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/21/2014 11:01 AM, Hubert Kario
      wrote:

    

    

      

        

        
From:
          "Eric Rescorla" <ekr@rtfm.com>

          To: tls@ietf.org

          Sent: Tuesday, 21 October, 2014 4:52:29 PM

          Subject: [TLS] Should we require compressed points

          


          

          
https://github.com/tlswg/tls13-spec/issues/80
            


            

            
Today we discussed the possibility of requiring support
              for compressed points

            
in TLS 1.3 now that the IPR has expired.

            


            

            
Specifically, I propose that for TLS 1.3, we:

            


            

            
- Use only compressed points for the existing curves
              (and presumably

            
  whatever superior format is defined for the
              CFRG-recommended

            
  curves, as appropriate).

            


            

            
- Deprecate the Supported Point Formats extension for
              TLS 1.3

            


            

            


            

            
For RFC 4492-bis, we might also consider requiring
              support for compressed

            
points as well as uncompressed (already required) but
              this seems like a

            
separable issue, since it's mostly in service of
              optimization rather than

            
simplicity.

          

        

        


        

        
How does that impact possibility of adding more "exotic"
          curves like curve25519/Ed25519

        
in some later point in time?

        

      

    

    

    My personal opinion is that there needs to be a complete separation
    in encodings and code points between X9.63 compliant EC data and
    anything else. 

    

    In the specific case of the curves you mention, unlike X9.63 curves,
    signing curves/keys and key agreement curves/keys are not
    interchangeable or compatible.  They are actually two different
    crypto systems and will probably require different code points  and
    maybe encodings.

    

    The other classes of curves that don't have an X9.63 (Montgomery?)
    representation will need similar treatment.

    

    Mike

    

    

      

        
-- 

        

        
Regards,

          Hubert Kario

        

      

      

      

      

      
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


    

    

  


--------------050804010503050206090102--


From nobody Tue Oct 21 08:27:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146301A87BA for ; Tue, 21 Oct 2014 08:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctOH1rMyiTVb for ; Tue, 21 Oct 2014 08:27:19 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352171A87E6 for ; Tue, 21 Oct 2014 08:26:52 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id hi2so11317106wib.3 for ; Tue, 21 Oct 2014 08:26:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=DbSimLnuxsp+wFqkaM9kD0rbTVOpwBVkuDR/b3j51Eg=; b=gEfC4RgpmI11HiE1iqvzxKN8I9kiTTuLKlxKtXF3+JjmHbz9HXJi596Y60gq2PZzeM D4b4zUHT3q0zIVXPvFHAQfYgHmT2JdBPiPAEcFpJwxm5CJraEk8czZwt75Gb1wqqLeWS YLc/SvB/mYG0XvxIiA/bm/LbIUBK3fGsReB96VqJcTr36j4DXyStx7/+Lpdj84Q1nJaO S1VrhtKfyWwBT2aSIymNv8PeTZWSnz3dSuRqby9//6wW7LttzDUfC+ygtxNiOxpD0RlK CyhD7H+0Sw8FQQTmVTLIFITnA3oI2uJTbtieYdXsFuhLB26lshgkQwgE5M9+biBNcxey d+bQ==
X-Received: by 10.180.184.129 with SMTP id eu1mr29530031wic.69.1413905209788;  Tue, 21 Oct 2014 08:26:49 -0700 (PDT)
Received: from [10.4.38.170] ([80.179.9.115]) by mx.google.com with ESMTPSA id fm4sm13446847wib.13.2014.10.21.08.26.41 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 08:26:49 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D67B73EC-D1B8-4A1A-B8EA-ED682409552D"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir 
In-Reply-To: 
Date: Tue, 21 Oct 2014 18:26:27 +0300
Message-Id: 
References:  <2108842737.16216761.1413903671102.JavaMail.zimbra@redhat.com> 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fJE4xTumlDi70DyVi6sGXglD3rY
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 15:27:25 -0000

--Apple-Mail=_D67B73EC-D1B8-4A1A-B8EA-ED682409552D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Oct 21, 2014, at 6:03 PM, Eric Rescorla  wrote:
>=20
>=20
> On Tue, Oct 21, 2014 at 5:01 PM, Hubert Kario > wrote:
> From: "Eric Rescorla" >
> To: tls@ietf.org 
> Sent: Tuesday, 21 October, 2014 4:52:29 PM
> Subject: [TLS] Should we require compressed points
>=20
>=20
> https://github.com/tlswg/tls13-spec/issues/80 =

>=20
> Today we discussed the possibility of requiring support for compressed =
points
> in TLS 1.3 now that the IPR has expired.
>=20
> Specifically, I propose that for TLS 1.3, we:
>=20
> - Use only compressed points for the existing curves (and presumably
>   whatever superior format is defined for the CFRG-recommended
>   curves, as appropriate).
>=20
> - Deprecate the Supported Point Formats extension for TLS 1.3
>=20
>=20
> For RFC 4492-bis, we might also consider requiring support for =
compressed
> points as well as uncompressed (already required) but this seems like =
a
> separable issue, since it's mostly in service of optimization rather =
than
> simplicity.
>=20
> How does that impact possibility of adding more "exotic" curves like =
curve25519/Ed25519
> in some later point in time?
>=20
> Hubert, thanks for your email.
>=20
> I don't think it should impact it at all because you still have to =
advertise the curves you
> support. My assumption is that advertising curve X would be the same =
as advertising
> that you could support its defined point format(s).
>=20

It does say that unless we re-introduce the extension, each curve with =
come with one single point format. I think that=E2=80=99s a fine idea =
that simplifies the code.

Yoav



--Apple-Mail=_D67B73EC-D1B8-4A1A-B8EA-ED682409552D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Oct 21, 2014, at 6:03 PM, Eric Rescorla <ekr@rtfm.com> =
wrote:


On Tue, Oct 21, 2014 at 5:01 PM, =
Hubert Kario <hkario@redhat.com> wrote:
From: "Eric Rescorla" <ekr@rtfm.com>
To: tls@ietf.org
Sent: Tuesday, 21 October, =
2014 4:52:29 PM
Subject: [TLS] Should we require =
compressed points


https://github.com/tlswg/tls13-spec/issues/80

Today we discussed the =
possibility of requiring support for compressed points
in TLS 1.3 now that the IPR has expired.

Specifically, I propose =
that for TLS 1.3, we:

- Use only compressed points for the existing curves (and =
presumably
  whatever superior format is =
defined for the CFRG-recommended
  curves, as =
appropriate).

- =
Deprecate the Supported Point Formats extension for TLS 1.3


For RFC 4492-bis, we might also consider requiring support =
for compressed
points as well as uncompressed =
(already required) but this seems like a
separable =
issue, since it's mostly in service of optimization rather =
than
simplicity.

How does that impact =
possibility of adding more "exotic" curves like =
curve25519/Ed25519
in some later point in =
time?

Hubert, thanks for your =
email.

I don't =
think it should impact it at all because you still have to advertise the =
curves you
support. My assumption is that =
advertising curve X would be the same as advertising
that you could support its defined point format(s).


It does say that unless we re-introduce the =
extension, each curve with come with one single point format. I think =
that=E2=80=99s a fine idea that simplifies the code.

Yoav


=

--Apple-Mail=_D67B73EC-D1B8-4A1A-B8EA-ED682409552D--


From nobody Tue Oct 21 08:28:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5A01A8826 for ; Tue, 21 Oct 2014 08:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2Bjx9ghY5t7 for ; Tue, 21 Oct 2014 08:28:23 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1046C1A1B7C for ; Tue, 21 Oct 2014 08:28:21 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id fb4so10437076wid.6 for ; Tue, 21 Oct 2014 08:28:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P2MfaVtQh7AcO7IEPqkQq+vrosLleKiG/wj1nJJ2l6A=; b=voDl3CgV2qo/Z2t+llyNmFWSpR0Vh8b5Dzha+NDzoVhFrBelPbMnWgRkCuK7+Ow7s4 jSi3lv6TfytIDAFSWsjpNghqby+BAa35ze9socKKRfVZ6PE2SerEjRxhROHGhlCHk8H/ DrTFu3N6kjHxjfX0g/yhBQZ4jEVRKUvQut+IvjtT73dv4Xzsv997qXZ6MB9O/NYn1+of 6mPZZ0rdkCMqNo0Y2ZoPl3kIyK5sqbpMq0eLoQiyY1ZjiTVTB2BU8Dpxc2Ze6K4V122z NRbp9AvMXJ8OgWgMbEIT4fA0Nu3GO7c0EXow1XwPf3OVXqBQ2chgz6jqZ9apcNxX6319 ix8Q==
X-Received: by 10.194.236.200 with SMTP id uw8mr44412032wjc.50.1413905296728;  Tue, 21 Oct 2014 08:28:16 -0700 (PDT)
Received: from [10.4.38.170] ([80.179.9.115]) by mx.google.com with ESMTPSA id ga7sm13465638wic.5.2014.10.21.08.28.15 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 08:28:16 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir 
In-Reply-To: <20141021143643.C8FB11AEFE@ld9781.wdf.sap.corp>
Date: Tue, 21 Oct 2014 18:28:12 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <8127E725-12C0-419D-A286-23C8CD0C931B@gmail.com>
References: <20141021143643.C8FB11AEFE@ld9781.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WMITgRSOOYTz5i8x4fOg3BaEPAQ
Cc: "" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 15:28:28 -0000

> On Oct 21, 2014, at 5:36 PM, Martin Rex  wrote:
>=20
> Andrei Popov wrote:
>>=20
>>> Oh, and given your affiliation, I was tempted to add:
>>> "So Microsoft are planning to roll out an update to Windows XP =
then?" :-).
>>=20
>> Hopefully, POODLE will help bring about the end of XP :)
>=20
> Windows XP, with MSIE 7 or MSIE 8 installed is *UNAFFECTED* by Poodle,
> because it will offer TLSv1.0 and not fallback to SSLv3 only.
>=20
> Win7 & Win8.x Users are affected by Poodle.

As are Firefox and Chrome users of Windows XP and people whose IE has =
TLSv1 disabled (as was the default through SP2).

Yoav


From nobody Tue Oct 21 09:01:56 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8B21A88CF for ; Tue, 21 Oct 2014 09:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6Pkyd00lMaI for ; Tue, 21 Oct 2014 09:01:52 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1B01A88C4 for ; Tue, 21 Oct 2014 09:01:51 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id EA4188185D; Tue, 21 Oct 2014 19:01:48 +0300 (EEST)
Date: Tue, 21 Oct 2014 19:01:48 +0300
From: Ilari Liusvaara 
To: Eric Rescorla 
Message-ID: <20141021160148.GA27810@LK-Perkele-VII>
References:  <2108842737.16216761.1413903671102.JavaMail.zimbra@redhat.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bQ46cNsbN9MrKXs5e5VHXBomTcw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 16:01:54 -0000

On Tue, Oct 21, 2014 at 05:03:27PM +0200, Eric Rescorla wrote:
> On Tue, Oct 21, 2014 at 5:01 PM, Hubert Kario  wrote:
> >
> > How does that impact possibility of adding more "exotic" curves like
> > curve25519/Ed25519
> > in some later point in time?
> >
> 
> Hubert, thanks for your email.
> 
> I don't think it should impact it at all because you still have to
> advertise the curves you
> support. My assumption is that advertising curve X would be the same as
> advertising
> that you could support its defined point format(s).

I would just lock the point format per curve for non-X9.63-compatible
stuff, at least for DH. That is, use curve-defined wire encoding,
regardless of what point formats extension says.

Also, there is another issue with non-X9.63-compatible stuff:
Encoding of the premaster secret. Proposal: Use usual wire encoding.

Disadvantage of this is that TLS 1.2- compatiblity would require
contradicting RFC 4492 (but specs contradicting base specs is not
unheard of) in order to ignore point formats and pms encoding.


Now with this, one could just stuff raw 32-byte curve25519 public
key into *KeyShare packet (with no prefix) and use the raw shared
secret as premaster secret (also 32 bytes).

And similarly for some XYZ curve that is twice the speed of
curve25519, but has really odd 48-byte point format.


-Ilari


From nobody Tue Oct 21 09:03:02 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C161A88D1 for ; Tue, 21 Oct 2014 09:02:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAipbxvyDpw5 for ; Tue, 21 Oct 2014 09:02:55 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5833E1A88D0 for ; Tue, 21 Oct 2014 09:02:55 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A651F2AB24B; Tue, 21 Oct 2014 16:02:47 +0000 (UTC)
Date: Tue, 21 Oct 2014 16:02:47 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141021160247.GP19158@mournblade.imrryr.org>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D3EAE@uxcn10-5.UoA.auckland.ac.nz> <96b88d73f776e16e3f5487643fb59a31.squirrel@www.trepanning.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <96b88d73f776e16e3f5487643fb59a31.squirrel@www.trepanning.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nICPJkt9ONJS6SDGUyZ5D1r2L20
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 16:02:57 -0000

On Mon, Oct 20, 2014 at 01:34:38PM -0700, Dan Harkins wrote:

> The ciphersuites are _completely oblivious_
> to the type and quality of the credential they use. You can't claim the
> _protocol_ is resistent to dictionary attack if the protocol can be used
> in a manner that makes it susceptible to dictionary attack.

No protocol is resistant to dictionary attack under the above
definition.

In TLS with DHE or ECDHE key agreement, the client's private exponent
may be drawn from the set "eeny, meeny, miny, moe" (suitably
encoded).  The server's secret may be drawn from "Chico, Harpo,
Groucho, Gummo, Zeppo".  Dictionary attack away!

-- 
	Viktor.


From nobody Tue Oct 21 09:07:41 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CD01A88DE for ; Tue, 21 Oct 2014 09:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQyK2yjk5QwW for ; Tue, 21 Oct 2014 09:07:30 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id C12791A88F6 for ; Tue, 21 Oct 2014 09:07:15 -0700 (PDT)
Received: from [174.236.34.54] (helo=Williams-MacBook-Pro.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Xgbxq-0001L5-P9 for tls@ietf.org; Tue, 21 Oct 2014 12:07:15 -0400
Date: Tue, 21 Oct 2014 09:07:14 -0700
From: Bill Frantz 
To: tls@ietf.org
X-Priority: 3
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7993c78f24c02fcc09ad87f4057f45abc3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 174.236.34.54
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/08T4HtMSVB11Y_6-VdKB3PVA7WA
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 16:07:33 -0000

On 10/20/14 at 10:32 AM, watsonbladd@gmail.com (Watson Ladd) wrote:

>After all these years you would think software vendors would test proper
>version negotiation before release.

Agreed. It doesn't take much of a test suite to check that a 1.2=20
server receiving 1.3 or 2.0 does the right thing. You don't even=20
have to know what exactly 1.2 or 2.0 means since the server=20
under test is going to offer its highest protocol: 1.2.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | If the site is supported by  | Periwinkle
(408)356-8506      | ads, you are the product.    | 16345=20
Englewood Ave
www.pwpconsult.com |                              | Los Gatos,=20
CA 95032


From nobody Tue Oct 21 09:20:02 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E611A890F for ; Tue, 21 Oct 2014 09:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ACzmwasFtP3 for ; Tue, 21 Oct 2014 09:19:55 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4917F1A8904 for ; Tue, 21 Oct 2014 09:19:55 -0700 (PDT)
Received: from mail-yh0-f50.google.com (mail-yh0-f50.google.com [209.85.213.50]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0LeyNP-1YTkcJ3GVL-00ql3H; Tue, 21 Oct 2014 18:19:53 +0200
Received: by mail-yh0-f50.google.com with SMTP id a41so1734142yho.37 for ; Tue, 21 Oct 2014 09:19:51 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.229.164 with SMTP id h34mr4380741yhq.199.1413908391567;  Tue, 21 Oct 2014 09:19:51 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Tue, 21 Oct 2014 09:19:51 -0700 (PDT)
In-Reply-To: <20141021150536.DA17C1AEFE@ld9781.wdf.sap.corp>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6@USMBX1.msg.corp.akamai.com> <20141021150536.DA17C1AEFE@ld9781.wdf.sap.corp>
Date: Tue, 21 Oct 2014 18:19:51 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c1db2a6ca9c40505f13310
X-Provags-ID: V02:K0:TxcrrPUdYcWe4bcozobDtII8+I1GnBhm+uzuw363HfN JdWS6ynPJsTse79xMtJue0zOJUVXQt0kwpTayXbRS6IIwy4EBP XjCpQj5px30mI4bjgsZLzvSfdUBYSp9O7QyDWtajZ8ardDDk4p iaHrrueH27oXQ8BVXNGZEj4ehEAa0TrrQITd3Mt7GpZ5aaEb/w o+NCy/T5t5yIkfcR8omV+ReIsA2wlpRrkhRf2knPp69YpOvwMc oADhXhY+mwSpqFwPafHm3svKFuR0diNhY+7fdptdxJWDU17FDg UoapyfLhAldwjp4Im+za+W6Zdb3ULTwpH8KL3KFD9pkXyu9rw8 /8W69nYKvqr21U+AURHbYWZw/zlRlUxpD2HUssShtc8LLx9Q+5 Di0znowUaQTZsJX0tUxSgRXDb1dBrIsPagRPFh5COlsT3/xcWp /KhtK
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fsiuvA-a33DoeVu5ZCL4DcxQM6Y
Subject: Re: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 16:19:57 -0000

--001a11c1db2a6ca9c40505f13310
Content-Type: text/plain; charset=UTF-8

Martin Rex :


> Rather than aborthing the TLS handshake, the server ought to include
> a TLS extension in the ServerHello indicating that he recognized a
> potentially inappropriate fallback and otherwise continue the TLS handshake
> in the regular fashion, leaving the decision of whether&how to continue
> entirely up to those clients who do perform insecure fallbacks.
>

That would work too, but the server would then be doing all the work to
send a ServerKeyExchange even if the client is going to abort the
connection.

This would also allow clients (browsers probably) to gather real data
> on potentially incorrect fallbacks, [...]


And it would then be a decision of the (fallback-performing) clients
> whether and when to start hard-failing, once they've sorted out their
> connection management and figured out how to deal with false positives
> in their fallback heuristics.
>

Well, even just having to fall back to make the connection work indicates
that something is wrong -- that's not a generally expected way of
establishing a TLS connection. (Clients can gather some statistics without
sending TLS_FALLBACK_SCSV if they want to use the connection regardless.)
It seems that the response mechanism that you propose would allow the
server to confirm to that client that the server noticed that the client
noticed that something is wrong. What would really be gained by that,
compared to what the current TLS_FALLBACK_SCSV protocol offers?

Bodo

--001a11c1db2a6ca9c40505f13310
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Mart=
in Rex <mrex@sap.com>:
=C2=A0

Rather than aborthing the TLS handshake, the server ought to include

a TLS extension in the ServerHello indicating that he recognized a

potentially inappropriate fallback and otherwise continue the TLS handshake=


in the regular fashion, leaving the decision of whether&how to continue=


entirely up to those clients who do perform insecure fallbacks.

That would work too, but the server would then be =
doing all the work to send a ServerKeyExchange even if the client is going =
to abort the connection.

This would also allow clie=
nts (browsers probably) to gather real data
on potentially incorrect fallbacks, =
[...]


And it would then be a decision of the (fallback-performing) clients

whether and when to start hard-failing, once they've sorted out their
connection management and figured out how to deal with false positives

in their fallback heuristics.

Well, eve=
n just having to fall back to make the connection work indicates that somet=
hing is wrong -- that's not a generally expected way of establishing a =
TLS connection. (Clients can gather some statistics without sending TLS_FAL=
LBACK_SCSV if they want to use the connection regardless.) It seems that th=
e response mechanism that you propose would allow the server to confirm to =
that client that the server noticed that the client noticed that something =
is wrong. What would really be gained by that, compared to what the current=
 TLS_FALLBACK_SCSV protocol offers?

Bodo



--001a11c1db2a6ca9c40505f13310--


From nobody Tue Oct 21 09:35:01 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDE91A88FD for ; Tue, 21 Oct 2014 09:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDQflnoj0iZz for ; Tue, 21 Oct 2014 09:34:56 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABBE1A8A4F for ; Tue, 21 Oct 2014 09:34:16 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8C3AD2AB109; Tue, 21 Oct 2014 16:34:14 +0000 (UTC)
Date: Tue, 21 Oct 2014 16:34:14 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141021163414.GQ19158@mournblade.imrryr.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org> <544606E5.2070807@fussenegger.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <544606E5.2070807@fussenegger.info>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-8PNw3J7F_iQUGvkeqUHMo_YMQI
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 16:34:58 -0000

On Tue, Oct 21, 2014 at 09:10:29AM +0200, Richard Fussenegger, BSc wrote:

> I was to vague in regards to implementation, sorry. Of course we only want a
> single key or rather one long blob of random data to manage. The idea of
> using a key length of at least the 'highest supported ciphers'[*] sounds
> very good to me and would honor the ciphers in use. By always using a 128
> bit key (current OpenSSL implementation) higher ciphers are essentially
> downgraded.

OpenSSL gives applications the freedom to use alternative keys and algorithms:

    http://www.postfix.org/postconf.5.html#tls_session_ticket_cipher

For now Postfix defaults to aes-128-cbc, I might change the default
to aes-256-cbc before 2.12 ships.

-- 
	Viktor.


From nobody Tue Oct 21 09:41:48 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3921A8A7E for ; Tue, 21 Oct 2014 09:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13hXfjnSckoq for ; Tue, 21 Oct 2014 09:41:46 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC081A8A7B for ; Tue, 21 Oct 2014 09:41:46 -0700 (PDT)
Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0MMJjd-1XmOrq3pID-0085fk; Tue, 21 Oct 2014 18:41:44 +0200
Received: by mail-yh0-f54.google.com with SMTP id 29so1993685yhl.27 for ; Tue, 21 Oct 2014 09:41:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.203.114 with SMTP id e78mr52239685yho.47.1413909702790;  Tue, 21 Oct 2014 09:41:42 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Tue, 21 Oct 2014 09:41:42 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6@USMBX1.msg.corp.akamai.com>
Date: Tue, 21 Oct 2014 18:41:42 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0158c7c4945a610505f18197
X-Provags-ID: V02:K0:A5CcTvCvPv1sWfUF8FZyXNVKe6eHPq34fezgs5kd3Bb 5KejvuvA0q2fQ8IyZ4wgWFlt/MUvECs1MToDG3Iy5i227epWoo u7Wt+SW6VUGzDiKPZ1wuPx3w5gyFmoHOoqJKbh7JzDytJggpT6 CDMcBAu/BLOB58ypv9zYlzIxVdOSX+0ScTL44AFoBSH8/PP9X9 BCATx/MN8yqjmydAG8nQ3Mn8DkeWVlA/d6t/4S7DVi9cISQjD1 9VT/4bYYOdmgRQqx3YUmmGByXVy7i2/Cwk8fSgPg513hiN0ect ROzVOkgybcNKk/hOaVYkW0cnD7gvd4uNpI3LmIxsqTkRyhxxFV DRm4ANE93aMQYpkG48VFo8lhZ0DcLfq84gGzohh3/Nt7kRhjgU Ry/nu4aH7/KEQf0XLkVGLsOPJxtPQ0mgXqQlzvjbSpKHNWaaNc /psoU
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7ziT069l2-t8SWh2T7IWuOp4oyQ
Subject: Re: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 16:41:48 -0000

--089e0158c7c4945a610505f18197
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Salz, Rich :

Here=E2=80=99s the draft minutes for today=E2=80=99s interim.  Please post =
corrections to
> the list.
>


> Discussion of RC4 draft.  Andrei via phone. Room strongly supports
> prohibiting RC4. Discussion about being able to address concerns raised b=
y
> a few. Chair will close discussion and move it forward. Sean to include
> text about =E2=80=9Cjust upgrade to TLS 1.2=E2=80=9D as we considered alt=
ernatives and
> rejected them in his shepard notes or equivalent. Mention that youtube
> encodes video streams using RC4 only.
>

That's not right: YouTube video streams currently can use two cipher
suites, TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA. The
interoperability problem mentioned in the meeting was that
TLS_RSA_WITH_AES_128_GCM_SHA256 (without ECDHE) isn't a supported cipher
suite in Firefox, and RC4 is RC4;
https://bugzilla.mozilla.org/show_bug.cgi?id=3D1029179.

Bodo

--089e0158c7c4945a610505f18197
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Salz=
, Rich <rsalz@akamai.com>:
=

Here=E2=80=99s the draft minutes for today=E2=80=99s=
 interim.=C2=A0 Please post corrections to the list.
=C2=A0
Discussion of RC4 draft.=C2=A0 =
Andrei via phone. Room strongly supports prohibiting RC4. Discussion about =
being able to address concerns raised by a few. Chair will close discussion=
 and move it forward. Sean to include text about =E2=80=9Cjust upgrade to T=
LS 1.2=E2=80=9D as we considered alternatives and rejected them in his shep=
ard notes or equivalent. Mention that youtube encodes video streams using R=
C4 only.

That's not rig=
ht: YouTube video streams currently can use two cipher suites, TLS_RSA_WITH=
_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA. The interoperability prob=
lem mentioned in the meeting was that TLS_RSA_WITH_AES_128_GCM_SHA256 (with=
out ECDHE) isn't a supported cipher suite in Firefox, and RC4 is RC4; <=
a href=3D"https://bugzilla.mozilla.org/show_bug.cgi?id=3D1029179">https://b=
ugzilla.mozilla.org/show_bug.cgi?id=3D1029179.

Bodo



--089e0158c7c4945a610505f18197--


From nobody Tue Oct 21 10:35:06 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE25B1A1B4B for ; Tue, 21 Oct 2014 10:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGQP69QFM0xA for ; Tue, 21 Oct 2014 10:35:03 -0700 (PDT)
Received: from mx201.easyname.com (mx201.easyname.com [212.232.28.122]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690A21A1B4A for ; Tue, 21 Oct 2014 10:35:02 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgdKh-0004Ma-Nt for tls@ietf.org; Tue, 21 Oct 2014 19:34:59 +0200
Message-ID: <5446992E.7000609@fussenegger.info>
Date: Tue, 21 Oct 2014 19:34:38 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org> <544606E5.2070807@fussenegger.info> <20141021163414.GQ19158@mournblade.imrryr.org>
In-Reply-To: <20141021163414.GQ19158@mournblade.imrryr.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000708030600080108040306"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9ULODmR7bW2ii6uqmVjvJpiYdtM
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 17:35:06 -0000

This is a cryptographically signed message in MIME format.

--------------ms000708030600080108040306
Content-Type: multipart/alternative;
 boundary="------------060801010107030303000508"

This is a multi-part message in MIME format.
--------------060801010107030303000508
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

Many thanks for this information, didn't know that until now.

Richard

On 10/21/2014 6:34 PM, Viktor Dukhovni wrote:
> On Tue, Oct 21, 2014 at 09:10:29AM +0200, Richard Fussenegger, BSc wrot=
e:
>
>> I was to vague in regards to implementation, sorry. Of course we only =
want a
>> single key or rather one long blob of random data to manage. The idea =
of
>> using a key length of at least the 'highest supported ciphers'[*] soun=
ds
>> very good to me and would honor the ciphers in use. By always using a =
128
>> bit key (current OpenSSL implementation) higher ciphers are essentiall=
y
>> downgraded.
> OpenSSL gives applications the freedom to use alternative keys and algo=
rithms:
>
>      http://www.postfix.org/postconf.5.html#tls_session_ticket_cipher
>
> For now Postfix defaults to aes-128-cbc, I might change the default
> to aes-256-cbc before 2.12 ships.
>


--------------060801010107030303000508
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    Many thanks for this
      information, didn't know that until now.

      

      Richard

      

    
    
On 10/21/2014 6:34 PM, Viktor Dukhovni=

      wrote:

    

    

      
On Tue, Oct 21, 2014 at 09:10:29AM +0200, Richard Fu=
ssenegger, BSc wrote:



      

        
I was to vague in regards to implementation, sorry=
=2E Of course we only want a
single key or rather one long blob of random data to manage. The idea of
using a key length of at least the 'highest supported ciphers'[*] sounds
very good to me and would honor the ciphers in use. By always using a 128=

bit key (current OpenSSL implementation) higher ciphers are essentially
downgraded.


      

      
OpenSSL gives applications the freedom to use alternative keys and algori=
thms:

    http://www.postfix.org/postconf.5=
=2Ehtml#tls_session_ticket_cipher

For now Postfix defaults to aes-128-cbc, I might change the default
to aes-256-cbc before 2.12 ships.



    

    

  


--------------060801010107030303000508--

--------------ms000708030600080108040306
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjExNzM0MzhaMCMGCSqGSIb3DQEJBDEWBBRB76nsamQCZ7NDBqabDOcvk30TOzBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEAjZ+yl3DhqcE1WBk9U7JeYv8YEKcQ
bhUFen+kljAjoQkyufp/ZAr6Y+6AybINeJDm3UiEGw6bmfUm4tJFzOCThHVIsX4qjIxQgS+f
ODkLRd8Tt96IH2cv1BMmotj2mYGS5VxZwTRoyudRLtAKbtnB7cElyKavCq9wB0JkoAAo6060
ZSvj0NRz1/3yzZ8q3Vc/VoZwb9wj442qWopWbJVA2VBQ+3zaN/hqzF8FeSMmpB+s6up7gWNW
gLthIEtoiItwMwSbL8YYwkI367Z2VV6zNUvAYhulbCZ/K55SoKwu44NZMW7aE4Pg5H7ESvhQ
8QzIJRL1wwMraVTHvni/P4BXkwAAAAAAAA==
--------------ms000708030600080108040306--


From nobody Tue Oct 21 11:34:08 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982741A8775 for ; Tue, 21 Oct 2014 11:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhnN88K19hB0 for ; Tue, 21 Oct 2014 11:34:06 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88151A8764 for ; Tue, 21 Oct 2014 11:34:05 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id p9so1539493lbv.19 for ; Tue, 21 Oct 2014 11:34:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q+GIubriOrHCX+oRalSo7NUvy5squzM+dKq8h2xD31c=; b=cwNhcuLmvFTnWENN9JCbqCW/enz49CnmwSC5VMxbNOWh8Eg0O1xOUWgzjMbuXTAItL uim8LofypODEudJQlvQvR6vjMf6ix7/QeC5EohF0FVVBKdIKNT9sqSL2jdtrDrQHYjeC JEusOVy8ktO1+z71SF6bPHSlQAQr5uq/K4UqMx97Hp3ZgQXV8Q3pAwKNbQ89z7E9/qb7 b9KwCjL2bxJW8zKQ1nrhFj+5kJy9AS7CtYxeekG1xgZPXHrA+Tgnh1bWWq3Q9tC2KM5O syKNrkITZrKMVOOVa86KG1TdlrpUnQIPPM17/KG7NDzQVS32RunvRb0Pjqq2CpfMkkPT yOsA==
X-Received: by 10.152.206.36 with SMTP id ll4mr37313595lac.64.1413916443992; Tue, 21 Oct 2014 11:34:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.218.145 with HTTP; Tue, 21 Oct 2014 11:33:43 -0700 (PDT)
In-Reply-To: <544606E5.2070807@fussenegger.info>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org> <544606E5.2070807@fussenegger.info>
From: David Leon Gil 
Date: Tue, 21 Oct 2014 14:33:43 -0400
Message-ID: 
To: "Richard Fussenegger, BSc" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/x7G3jecZfdEAdvdIFbqC043Kkvw
Cc: tls@ietf.org
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 18:34:07 -0000

On Tue, Oct 21, 2014 at 3:10 AM, Richard Fussenegger, BSc
 wrote:
> I'm [. . .] glimpsing over to the fact that the
> cryptography community agrees that 128 bit security will be enough for the
> next 10 to 20 years.[2]

This really isn't true. See djb's "matching AES security" at
https://www.ietf.org/mail-archive/web/cfrg/current/msg04820.html

Summarizing: The workfactor of a multi-target attack is much lower for
symmetric-key crypto than for attacks against asymmetric-key crypto.
This is exactly the sort of attack that is useful for mass
surveillance.

We need to start moving away from AES-128 now, not in 10 years.

(Note that a number of cryptographers think that 2^90 operations per
year is feasible today; djb is lowballing the number a bit.)


From nobody Tue Oct 21 11:45:56 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDA61A8775 for ; Tue, 21 Oct 2014 11:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.968
X-Spam-Level: 
X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib74_nZYfP2F for ; Tue, 21 Oct 2014 11:45:49 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D499D1A8761 for ; Tue, 21 Oct 2014 11:45:48 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6511610224008; Tue, 21 Oct 2014 11:45:48 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 21 Oct 2014 11:45:48 -0700 (PDT)
Message-ID: <3653ffe169c72f3302d605a4bc24bb0d.squirrel@www.trepanning.net>
In-Reply-To: <20141021160247.GP19158@mournblade.imrryr.org>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D3EAE@uxcn10-5.UoA.auckland.ac.nz> <96b88d73f776e16e3f5487643fb59a31.squirrel@www.trepanning.net> <20141021160247.GP19158@mournblade.imrryr.org>
Date: Tue, 21 Oct 2014 11:45:48 -0700 (PDT)
From: "Dan Harkins" 
To: tls@ietf.org
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LMIDjPTAFGADjBPPN_55DBMIFRA
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 18:45:51 -0000

On Tue, October 21, 2014 9:02 am, Viktor Dukhovni wrote:
> On Mon, Oct 20, 2014 at 01:34:38PM -0700, Dan Harkins wrote:
>
>> The ciphersuites are _completely oblivious_
>> to the type and quality of the credential they use. You can't claim the
>> _protocol_ is resistent to dictionary attack if the protocol can be used
>> in a manner that makes it susceptible to dictionary attack.
>
> No protocol is resistant to dictionary attack under the above
> definition.

  The point is that increasing the size of the PSK does not make the
_protocol_ resistant to dictionary attack. It just makes the attack
harder to successfully conclude.

  This is not my definition by the way. But instead of paraphrasing, let
me quote from "Authenticated Key Exchange Secure Against Dictionary
Attacks" by Bellare, Pointcheval, and Rogaway:

        "A theorem asserting security of some protocol make qualitative
         how much _computation_ helps and just how much _interaction_
         does. One sees whether or not one has security against dictionary
         attacks by looking to see if maximal adversarial advantage grows
         primarily with the ratio of interaction to the size of the password
         space."

Increasing the size of the PSK just makes the "password space" larger
but that has no effect on interaction. With the TLS PSK ciphersuites,
there's one interaction and then there's a whole bunch of computation.
Increasing the amount of computation necessary doesn't make the
protocol resistant to dictionary attack because there's still just one
interaction-- the adversarial advantage does not grow primarily with
the ratio of interaction to the size of the search space.

  And there are protocols that are resistant to dictionary attack under
that definition. There's one in the paper. Or look at your favorite PAKE.

  Dan.



From nobody Tue Oct 21 11:57:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDA81A8775 for ; Tue, 21 Oct 2014 11:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFe3GB2KyTuG for ; Tue, 21 Oct 2014 11:56:57 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF851A1BC8 for ; Tue, 21 Oct 2014 11:56:57 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0F90510224008; Tue, 21 Oct 2014 11:56:57 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 21 Oct 2014 11:56:57 -0700 (PDT)
Message-ID: 
In-Reply-To: 
References: 
Date: Tue, 21 Oct 2014 11:56:57 -0700 (PDT)
From: "Dan Harkins" 
To: "Eric Rescorla" 
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MhNoDIgjfZJqEQjpz5HheUujixk
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 18:57:03 -0000

  Hi Eric,

  I agree with your proposal.

  Dan.

On Tue, October 21, 2014 7:52 am, Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/issues/80
>
> Today we discussed the possibility of requiring support for compressed
> points
> in TLS 1.3 now that the IPR has expired.
>
> Specifically, I propose that for TLS 1.3, we:
>
> - Use only compressed points for the existing curves (and presumably
>   whatever superior format is defined for the CFRG-recommended
>   curves, as appropriate).
>
> - Deprecate the Supported Point Formats extension for TLS 1.3
>
>
> For RFC 4492-bis, we might also consider requiring support for compressed
> points as well as uncompressed (already required) but this seems like a
> separable issue, since it's mostly in service of optimization rather than
> simplicity.
>
> What do people think?
> -Ekr
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



From nobody Tue Oct 21 12:20:55 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615591A1A52 for ; Tue, 21 Oct 2014 12:20:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BCm2CxHFe9W for ; Tue, 21 Oct 2014 12:20:47 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02591A1A3E for ; Tue, 21 Oct 2014 12:20:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=baP7oqFJKWEqPH45mlj9lCj8gAXikD6Fym1Ojv68JpE=;  b=NFRWp+6KisAsILeQYkUc+RWTm5urb168tk61mECkNEWdiqsh+I1hMh1NNKIK3yGnZXXyDZLpP2kUfoxfVRRnhzOUZd3tPdMmRhkCgxrqV6k85r/AF5GoOsb2oIdWV3Etegg/GITRnLK9yx0DZuFxU+JDAR1slq9Cc3DAlBp/xa0=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xgez2-0005yf-8H; Tue, 21 Oct 2014 21:20:40 +0200
Message-ID: <5446B20B.4030007@polarssl.org>
Date: Tue, 21 Oct 2014 21:20:43 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Martin Thomson ,  "Richard Fussenegger, BSc" 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org> <544606E5.2070807@fussenegger.info> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wJu5uU918ItIb45xjsC9EHbr8Co
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 19:20:49 -0000

On 21/10/2014 09:27, Martin Thomson wrote:
> On 21 October 2014 00:10, Richard Fussenegger, BSc
>  wrote:
>> The idea of using a key length of at least the 'highest supported
>> ciphers'[*] sounds very good to me
> 
> There is no technical reason that you would want a minimum length on
> the ticket.  If you are using stateful resumption, a ticket of "1" or
> "2" is perfectly sufficient.
> 
I think there's a misunderstading here: it's about the size of the *key* used to
encrypted the ticket in case it's an actual ticket (as opposed to the more
general "token" notion).

Manuel.


From nobody Tue Oct 21 13:33:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D508E1A01BA for ; Tue, 21 Oct 2014 13:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdVfD6Cwfheg for ; Tue, 21 Oct 2014 13:33:30 -0700 (PDT)
Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319981A6FB2 for ; Tue, 21 Oct 2014 13:33:30 -0700 (PDT)
Received: by mail-oi0-f52.google.com with SMTP id a3so1614469oib.39 for ; Tue, 21 Oct 2014 13:33:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b5syxALpdEdMRIE9l45wIzEjPcOBvEfJEQNFwNtk5vU=; b=eRrokqRHKNGzArbhJl1CWLtmAVk1NBG+tLGuNHGIGu6ULCsURiovtpmfHC4F3S5hni /qrLa2uDJs6w2yAsA5zq9lfDIBGA+sDPWGDROPEXyMYseY3dRJBbGFBq8vRDfML5b4i7 kvJNOmeBJqcmuYnUZdm7/lV5Mw7U+/xr7IOsyPQ1YDDZxKaKEaqaVfAGrygnXB1R5367 Qxu1b3LCD2jskNctP45euDkk/F19TOnI7ZkI5GyAbwPo/whfZFCL8q1ugVRC03pE1Rl6 80QsxcmP5z+LssyOlfan+ovElGQ3jiqo8bpnIsqsRiBhDlJ5f0RI++ziKPDSl51VQOFM ZxBQ==
X-Gm-Message-State: ALoCoQlQ5gN3SutFHHO8kDcAIKEedH7jAJVJbgSHxLoiLKxH0OZ1WwY4eWoglpI9KkCAQCZ6uMsv
MIME-Version: 1.0
X-Received: by 10.202.3.70 with SMTP id 67mr4282126oid.69.1413923609481; Tue, 21 Oct 2014 13:33:29 -0700 (PDT)
Received: by 10.76.93.9 with HTTP; Tue, 21 Oct 2014 13:33:29 -0700 (PDT)
In-Reply-To: <54455AFB.1060401@polarssl.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <54450068.5020101@polarssl.org>   <54455AFB.1060401@polarssl.org>
Date: Tue, 21 Oct 2014 13:33:29 -0700
Message-ID: 
From: Brian Smith 
To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= 
Content-Type: multipart/alternative; boundary=001a113b9bba7baaad0505f4beba
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wdcczmK2GADCZUuq4Nl19ta4te0
Cc: "Joseph Salowey \(jsalowey\)" , "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 20:33:32 -0000

--001a113b9bba7baaad0505f4beba
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 20, 2014 at 11:56 AM, Manuel P=C3=A9gouri=C3=A9-Gonnard 
wrote:

> On 20/10/2014 19:32, Brian Smith wrote:
> > For compatibility reasons, clients should put the renegotiation info an=
d
> > TLS_FALLBACK_SCSV at the end of the cipher suite list, to avoid this bu=
g
> > and similar bugs in other server software. This should be added to the
> > draft too.
> >
> Currently, PolarSSL puts the renego SCSV at the beginning of the list and
> we
> didn't get any report of interop issues so far. However, if there's
> consensus
> that it's safer to put the SCSV at the end, I'll follow your advice and
> change that.
>
> (For the fallback scsv, obviously I added it at the end since we want to
> interop
> with the current version of OpenSSL.)
>

I am not sure if it is problematic to put the renegotiation_info SCSV
anywhere except the end. In NSS, it has always been at the end, as far as I
know. Not too long ago, NSS was changed to always use the TLS extension
instead of the SCSV except for SSL 3.0; see [1] for why. However, in
retrospect, this might have increased the amount of TLS extension
intolerance seen by NSS-based applications, if some servers are intolerant
to the renegotation_info extension but not other ones sent by NSS.

In the case of TLS_FALLBACK_SCSV, it was assigned the value { 0x56, 0x00 }.
>From past experience, we know that some implementations only look at the
second byte of the value. This means that some implementations may confuse
TLS_FALLBACK_SCSV with { 0x00, 0x00 }, which is TLS_NULL_WITH_NULL_NULL.  T=
hus,
if you put TLS_FALLBACK_SCSV ahead of any real cipher suites, some
implementations may attempt to negotiation TLS_NULL_WITH_NULL_NULL,
especially if that implementation is attempting to honor the client's
cipher suite preference order. If that were to happen, the best case
scenerio is that your client will refuse the server's choice of
TLS_NULL_WITH_NULL_NULL,
which is not good. By putting TLS_FALLBACK_SCSV at the end, you avoid this
problem with these broken servers, assuming you offer some cipher suite
that they actually support. See [2]. Note that these kind of broken servers
are the reason you'd be doing TLS intolerance fallback in the first place.

Cheers,
Brian

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=3D549042#c4
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=3D946147#c5

--001a113b9bba7baaad0505f4beba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Oct 20, 2014 at 11:56 AM, Manuel P=C3=A9gouri=C3=A9-Gonnard <mpg@pola=
rssl.org> wrote:
On 20=
/10/2014 19:32, Brian Smith wrote:

> For compatibility reasons, clients should put the renegotiation info a=
nd

> TLS_FALLBACK_SCSV at the end of the cipher suite list, to avoid this b=
ug

> and similar bugs in other server software. This should be added to the=


> draft too.

>

Currently, PolarSSL puts the renego SCSV at the beginning of the lis=
t and we

didn't get any report of interop issues so far. However, if there's=
 consensus

that it's safer to put the SCSV at the end, I'll follow your advice=
 and change that.



(For the fallback scsv, obviously I added it at the end since we want to in=
terop

with the current version of OpenSSL.)

I=
 am not sure if it is problematic to put the renegotiation_info SCSV anywhe=
re except the end. In NSS, it has always been at the end, as far as I know.=
 Not too long ago, NSS was changed to always use the TLS extension instead =
of the SCSV except for SSL 3.0; see [1] for why. However, in retrospect, th=
is might have increased the amount of TLS extension intolerance seen by NSS=
-based applications, if some servers are intolerant to the renegotation_inf=
o extension but not other ones sent by NSS.

In the=
 case of TLS_FALLBACK_SCSV, it was assigned the value {=C2=A00x56, 0x00 }. From past experience, we kno=
w that some implementations only look at the second byte of the value. This=
 means that some implementations may confuse TLS_FALLBACK_SCSV with { 0x00,=
 0x00 }, which is=C2=A0TLS_NULL_WITH_NULL_NULL. =C2=A0Thus, if you put TLS_FALL=
BACK_SCSV ahead of any real cipher suites, some implementations may attempt=
 to negotiation=C2=A0TLS_NULL_WITH_NULL_NULL, especially i=
f that implementation is attempting to honor the client's cipher suite =
preference order. If that were to happen, the best case scenerio is that yo=
ur client will refuse the server's choice of=C2=A0TLS_=
NULL_WITH_NULL_NULL, which is not good. By putting=C2=A0TLS_FALLBACK=
_SCSV at the end, you avoid this problem with these broken servers, assumin=
g you offer some cipher suite that they actually support. See [2]. Note tha=
t these kind of broken servers are the reason you'd be doing TLS intole=
rance fallback in the first place.

Cheers,
Brian




--001a113b9bba7baaad0505f4beba--


From nobody Tue Oct 21 13:42:51 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438721A6FB1 for ; Tue, 21 Oct 2014 13:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2zKy6crNYfT for ; Tue, 21 Oct 2014 13:42:47 -0700 (PDT)
Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5A81A6FE0 for ; Tue, 21 Oct 2014 13:42:47 -0700 (PDT)
Received: by mail-oi0-f53.google.com with SMTP id v63so1635587oia.40 for ; Tue, 21 Oct 2014 13:42:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FqQj9wVXOOCZWi/zLxAVmX0o1SQEs+Ad9UsYDlkoggU=; b=QHukTw596LtLrp0aBnyyXpdZO9ONNbYiDhT3LX7v8u2k9uurRKQq+sY+mx7Y7ZBKq+ teWDBsVSapeWAy9pXhP3Z63ZMKCqbqhdC1Og1U37PyqbXfV+igxrP+dpSpNi4Z27CKUv TT/Ka+hh9pPIuswk7jKAnZ6K44ahW24UdtV0NMsx8Uj9w/p5BeqYrOmiEX5AY1GPJSlW aPpAnyFAPvnhjTzcNN8sNLHf5K1oDSVHxUvQX3qAlvr1Lqrdwz7MDwTSNoMhkrFKmbc1 yIBd+Xsc3SlSvANvC/1aNXHKW9U82E9xQKtYppPL3raXX59Y7XXdAdLeattGJzVRXRSc NVDA==
X-Gm-Message-State: ALoCoQlDiiRIvCNVs6vpJ5DBgLA0oThA4lK1swmT0Bf1qitxWu80nICxc2lJIae8ICZFdMQ6wlGy
MIME-Version: 1.0
X-Received: by 10.60.74.137 with SMTP id t9mr6071344oev.34.1413924167031; Tue, 21 Oct 2014 13:42:47 -0700 (PDT)
Received: by 10.76.93.9 with HTTP; Tue, 21 Oct 2014 13:42:46 -0700 (PDT)
In-Reply-To: <20141021100324.GA12704@LK-Perkele-VII>
References: <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>  <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com>   <54462E27.30607@comodo.com> <20141021100324.GA12704@LK-Perkele-VII>
Date: Tue, 21 Oct 2014 13:42:46 -0700
Message-ID: 
From: Brian Smith 
To: Ilari Liusvaara 
Content-Type: multipart/alternative; boundary=001a113439aab7339e0505f4df8e
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KmgtUfGsD_JaDLZoBXtlh0oOvlE
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call fordraft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 20:42:49 -0000

--001a113439aab7339e0505f4df8e
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 21, 2014 at 3:03 AM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> On Tue, Oct 21, 2014 at 10:57:59AM +0100, Rob Stradling wrote:
> >
> > How about negotiating TLS 1.3 using yet another new SCSV?
> >
> > Yes, I know, that'd be even more of a hack than negotiating TLS 1.3 with
> a
> > new extension.  But since server-side support for extensions is optional,
> > and since there are servers out there that are extension-intolerant, I
> > figured I should at least suggest the idea.  ;-)
>
> One needs extensions anyway in order to transport data required for
> TLS 1.3 handshake (groups supported and key shares for subset of those).
>

 Yes, and also more fundamental things like the server_name and
status_request extensions. I think after TLS_FALLBACK_SCSV, we should avoid
new SCSVs.

Cheers,
Brian

--001a113439aab7339e0505f4df8e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Oct 21, 2014 at 3:03 AM, Ilari Liusvaara <ilari.liusvaara@e=
lisanet.fi> wrote:
On Tue, Oct 21, 2014 at 10:57:59AM +0100, Rob Stradling wrote:

>

> How about negotiating TLS 1.3 using yet another new SCSV?

>

> Yes, I know, that'd be even more of a hack than negotiating TLS 1.=
3 with a

> new extension.=C2=A0 But since server-side support for extensions is o=
ptional,

> and since there are servers out there that are extension-intolerant, I=


> figured I should at least suggest the idea.=C2=A0 ;-)



One needs extensions anyway in order to transport data required for<=
br>
TLS 1.3 handshake (groups supported and key shares for subset of those).

=C2=A0Yes, and also more fundamental thin=
gs like the server_name and status_request extensions. I think after TLS_FA=
LLBACK_SCSV, we should avoid new SCSVs.

Cheers,
Brian


--001a113439aab7339e0505f4df8e--


From nobody Tue Oct 21 14:35:57 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57C81A874B for ; Tue, 21 Oct 2014 14:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0AiDl1qwgCh for ; Tue, 21 Oct 2014 14:35:52 -0700 (PDT)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F141A8761 for ; Tue, 21 Oct 2014 14:35:51 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 35036699E8; Wed, 22 Oct 2014 00:35:47 +0300 (EEST)
Date: Wed, 22 Oct 2014 00:35:47 +0300
From: Ilari Liusvaara 
To: Dan Harkins 
Message-ID: <20141021213547.GA31199@LK-Perkele-VII>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D3EAE@uxcn10-5.UoA.auckland.ac.nz> <96b88d73f776e16e3f5487643fb59a31.squirrel@www.trepanning.net> <20141021160247.GP19158@mournblade.imrryr.org> <3653ffe169c72f3302d605a4bc24bb0d.squirrel@www.trepanning.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <3653ffe169c72f3302d605a4bc24bb0d.squirrel@www.trepanning.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZdcEret6Fw-gJcf1UjEcua848Q4
Cc: tls@ietf.org
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 21:35:54 -0000

On Tue, Oct 21, 2014 at 11:45:48AM -0700, Dan Harkins wrote:
> 
> On Tue, October 21, 2014 9:02 am, Viktor Dukhovni wrote:
> > On Mon, Oct 20, 2014 at 01:34:38PM -0700, Dan Harkins wrote:
> >
> >> The ciphersuites are _completely oblivious_
> >> to the type and quality of the credential they use. You can't claim the
> >> _protocol_ is resistent to dictionary attack if the protocol can be used
> >> in a manner that makes it susceptible to dictionary attack.
> >
> > No protocol is resistant to dictionary attack under the above
> > definition.
> 
>   The point is that increasing the size of the PSK does not make the
> _protocol_ resistant to dictionary attack. It just makes the attack
> harder to successfully conclude.

>   And there are protocols that are resistant to dictionary attack under
> that definition. There's one in the paper. Or look at your favorite PAKE.

There is a difference between collecting enough information to break
the protocol (which is quite little with _any_ practical protocol) and
collecting enough information to "easily" break the protocol.


Whole practical cryptography is based on the assumption that it doesn't
matter if attacker has enough information to break it, if the
computation is just too titanic.


However, if you have things like long-term passwords involved, that
are easily breakable (due to insufficient entropy) given some
information, one wants to make collecting that information hard.
This is what PAKEs are about.


However, proper PSKs have high entropy, so even with enough
information, it is very difficult to break one.



-Ilari


From nobody Tue Oct 21 15:34:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA711A8701 for ; Tue, 21 Oct 2014 15:34:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQDXo6FMJTQJ for ; Tue, 21 Oct 2014 15:34:29 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4B01A877E for ; Tue, 21 Oct 2014 15:34:28 -0700 (PDT)
Received: from mail-yh0-f46.google.com (mail-yh0-f46.google.com [209.85.213.46]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0Lbqzs-1YNV0H3K5s-00jKY7; Wed, 22 Oct 2014 00:34:26 +0200
Received: by mail-yh0-f46.google.com with SMTP id f10so331398yha.5 for ; Tue, 21 Oct 2014 15:34:22 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.60.195 with SMTP id u43mr13580757yhc.142.1413930862562;  Tue, 21 Oct 2014 15:34:22 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Tue, 21 Oct 2014 15:34:22 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6@USMBX1.msg.corp.akamai.com>
Date: Wed, 22 Oct 2014 00:34:22 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c1ef7cccdb6e0505f66ec6
X-Provags-ID: V02:K0:Lzp6g4s+CZZZPzASCJC42aZyZlMEWH3EgU29j0YR182 qwuFAgZtB38BvISu9SADEXX4a/QzElw2DksYoW7b33gc1hrYYX 5WAi8tB/iN0YwC22IVvIXszhRWjT2yyzIUekTZJ6cIXnR8Ol0R 0698BbbGzqbgN77GKnmhqTTM0P9uGqoI5OytBphreidKgB3YMU zCnHhOL+LBsaL2nVgRSq5+vxm8oSQLFNj5rIdQavRfGGw1v9Ud PaGeGDlZvn2+MgFLli7VmcODZGYdp90qKrYv2iWsnp3BKQn35N QXZdctTNqP1x5FyChIQDVuOl0bgSe3fsT1blKaRUXRrsVXn/6m cRjjtPqE0NStXLkryijv6ftfsuJh9gkhh3d4PKllBGCEzmwkEA zQf3po23K6dXw/8awpl8azi9SJ9rGVdcjXu87mTI2AQqpZuHfy z/rA6
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/j1b8nVvkEJF_z-cEfqg-kJFIg90
Subject: Re: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 22:34:30 -0000

--001a11c1ef7cccdb6e0505f66ec6
Content-Type: text/plain; charset=UTF-8

Salz, Rich :


> Bodo slides are at
> https://github.com/tlswg/wg-materials/blob/master/20141021_interim/TLS_FALLBACK_SCSV_IETF_TLS_Interim_Oct_2014.pdf
>

More official link:
http://www.ietf.org/proceedings/interim/2014/10/21/tls/slides/slides-interim-2014-tls-3-1.pdf

--001a11c1ef7cccdb6e0505f66ec6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Salz=
, Rich <rsalz@akamai.com>:
=C2=A0

More official link: <=
a href=3D"http://www.ietf.org/proceedings/interim/2014/10/21/tls/slides/sli=
des-interim-2014-tls-3-1.pdf">http://www.ietf.org/proceedings/interim/2014/=
10/21/tls/slides/slides-interim-2014-tls-3-1.pdf



--001a11c1ef7cccdb6e0505f66ec6--


From nobody Tue Oct 21 18:10:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607D21A88E5 for ; Tue, 21 Oct 2014 18:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhZdpBohY9sN for ; Tue, 21 Oct 2014 18:09:51 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:710]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF881A88D9 for ; Tue, 21 Oct 2014 18:09:50 -0700 (PDT)
Received: from BY2PR03MB554.namprd03.prod.outlook.com (10.141.141.156) by BY2PR03MB556.namprd03.prod.outlook.com (10.141.142.145) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 01:09:27 +0000
Received: from BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) by BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) with mapi id 15.00.1054.004; Wed, 22 Oct 2014 01:09:27 +0000
From: Marsh Ray 
To: "mrex@sap.com" , "Salz, Rich" 
Thread-Topic: [TLS] Minutes from Tuesday
Thread-Index: Ac/s/80MFVvbkl4TRbKNfELmt8XWcwAQKq0AABRz8dA=
Date: Wed, 22 Oct 2014 01:09:27 +0000
Message-ID: <9a38ce96a67b4cb4bae5074bb9a6cf5d@BY2PR03MB554.namprd03.prod.outlook.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6@USMBX1.msg.corp.akamai.com> <20141021150536.DA17C1AEFE@ld9781.wdf.sap.corp>
In-Reply-To: <20141021150536.DA17C1AEFE@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ee31::2]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB556;
x-forefront-prvs: 037291602B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(189002)(199003)(86612001)(106356001)(86362001)(95666004)(99286002)(105586002)(92566001)(4396001)(2656002)(87936001)(85852003)(19580395003)(19580405001)(107046002)(76482002)(101416001)(40100003)(31966008)(122556002)(20776003)(120916001)(99396003)(54356999)(76176999)(50986999)(85306004)(21056001)(97736003)(2501002)(74316001)(33646002)(108616004)(46102003)(80022003)(76576001)(64706001)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB556; H:BY2PR03MB554.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eAc7bLZ2izDP5-lGqKIO0ZJ8JDk
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 01:10:10 -0000

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex
Sent: Tuesday, October 21, 2014 8:06 AM
> Rather than aborthing the TLS handshake, the server ought to=20
> include a TLS extension in the ServerHello indicating that he=20
> recognized a potentially inappropriate fallback

Even better would be something the client could authenticate,
but that an attacker might not be able to detect without a
full real-time compromise of the master secret. E.g.,
invert all the bits in the Finished message.

> and otherwise=20
> continue the TLS handshake in the regular fashion
> clients who do perform insecure fallbacks.
>
> This would also allow clients (browsers probably) to gather=20
> real data on potentially incorrect fallbacks, rather than=20
> have users face random connection failures.

If the client was really determined to use a downgraded connection,
it could always just connect again without FALLBACK_SCSV.

But that would be stupid.

- Marsh


From nobody Tue Oct 21 18:36:05 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43DE1A8968 for ; Tue, 21 Oct 2014 18:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level: 
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvNwVyorAOJQ for ; Tue, 21 Oct 2014 18:36:02 -0700 (PDT)
Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C232D1A895E for ; Tue, 21 Oct 2014 18:36:02 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id o8so2041766qcw.31 for ; Tue, 21 Oct 2014 18:36:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0vgzJxf2qMV0F9Cf87KJVca16bTeduZT/O2h1iZEbvQ=; b=nFCEf9jypUM2+cr9BkHIW67uOdxA6Wn0KiqxG1Sgl9ExsDQWuwJdVWS78XI87nux0O 4vsc/mrId68n4md/jyQDAvuDnyBYmxA8d+ZHw5tMR9h4ed4kTXRGYfv+EH2Ou+BchZLW oGZHTDUflFeRXGbnDlrmIdl9nDZGqmvRZLG5QRfbf7i36G0xgsf8gVOz7j0G0TtQwHNr 6FaKIyoQ/lFcYiycGjhigMhq5FZwQhjBTDIGJsf16O/HZqqJp8yawfLx/Bf+C1GWU5Mn Hwdxuxa37grKlJ2ToA08SgsWvzs/amhwjdWGf2j7+A+Ew+0wmZE2Efleu/d1VvlupQuu GrOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0vgzJxf2qMV0F9Cf87KJVca16bTeduZT/O2h1iZEbvQ=; b=AQFUeuoH8BQpjegCpLmdj106ZTtDcItJeyIt0IQkYaJOOFquE7r9l21WpWju3YXvvO nDNEFXmRICfcUbFzC0W1hTFlth6iy96hNgqrwDAmxlz0s3SDa4pSzjGiRbY36Kl1wd4c 0H3yEna2ao1j+WPJ+AiwReYnEIu/yr3R3OflAKKf5jgAzRd3Trl6SCBgWy68jqHhVlQB 2Yarj2HMaQnAlwcQ6E3mL9xIvb5OhSXsItUVvurwRtoJJp9CS8wpLfSZJb3QZuwa28l7 M2oLbMROYmQsKT4UV37WYT0zFthHMT0XRM0Y6q7Y7E7D+tXI640JVfvflhVegjFsyiBw Z47g==
X-Gm-Message-State: ALoCoQmlsuYu8Vtex+ENC/sWwmc6JALCyw95sb+x/FTTxMb6WT12VXAXXADSxJrv7aXho2QeN6r8
X-Received: by 10.140.108.67 with SMTP id i61mr33796397qgf.90.1413941761988; Tue, 21 Oct 2014 18:36:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.88.72 with HTTP; Tue, 21 Oct 2014 18:35:41 -0700 (PDT)
In-Reply-To: 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6@USMBX1.msg.corp.akamai.com> 
From: Adam Langley 
Date: Tue, 21 Oct 2014 18:35:41 -0700
Message-ID: 
To: Bodo Moeller 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lBC76ozUlUIS2ndizGQtjJ-rWfs
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 01:36:04 -0000

On Tue, Oct 21, 2014 at 9:41 AM, Bodo Moeller  wrote:
> That's not right: YouTube video streams currently can use two cipher suites,
> TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA. The
> interoperability problem mentioned in the meeting was that
> TLS_RSA_WITH_AES_128_GCM_SHA256 (without ECDHE) isn't a supported cipher
> suite in Firefox, and RC4 is RC4;
> https://bugzilla.mozilla.org/show_bug.cgi?id=1029179.

(And TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 support is coming -- it's
already enabled in some locations.)


Cheers

AGL


From nobody Tue Oct 21 19:33:07 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A6C1A8A46 for ; Tue, 21 Oct 2014 19:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03IOQ8wL_BeN for ; Tue, 21 Oct 2014 19:33:04 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id BA5E21A8A3E for ; Tue, 21 Oct 2014 19:33:04 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E96F9284E0; Wed, 22 Oct 2014 02:33:03 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id D31CA284C6; Wed, 22 Oct 2014 02:33:03 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id CFAD1202A; Wed, 22 Oct 2014 02:33:03 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 21 Oct 2014 22:32:56 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Tue, 21 Oct 2014 22:32:56 -0400
From: "Salz, Rich" 
To: "mrex@sap.com" 
Date: Tue, 21 Oct 2014 22:32:55 -0400
Thread-Topic: [TLS] Minutes from Tuesday
Thread-Index: Ac/tQHvffZTQ9s5pRrucjElxfAobNgAX+lCg
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4D75@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6@USMBX1.msg.corp.akamai.com> <20141021150536.DA17C1AEFE@ld9781.wdf.sap.corp>
In-Reply-To: <20141021150536.DA17C1AEFE@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AOFVEj0sm_UXarNHiwtEddYh_1s
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 02:33:05 -0000

> The current fallback-scsv is embarrassing.

You seem to be the only one who thinks this.

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Wed Oct 22 02:15:42 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA751A8AFC for ; Wed, 22 Oct 2014 02:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Level: 
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy-84vpxyXcn for ; Wed, 22 Oct 2014 02:15:39 -0700 (PDT)
Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FA31A8AE4 for ; Wed, 22 Oct 2014 02:15:39 -0700 (PDT)
Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1Xgs0z-0002BO-UV; Wed, 22 Oct 2014 11:15:33 +0200
Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1Xgs0z-0005up-Mg; Wed, 22 Oct 2014 11:15:33 +0200
From: Florian Weimer 
To: "Salz\, Rich" 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6@USMBX1.msg.corp.akamai.com> <20141021150536.DA17C1AEFE@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4D75@USMBX1.msg.corp.akamai.com>
Date: Wed, 22 Oct 2014 11:15:33 +0200
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4D75@USMBX1.msg.corp.akamai.com> (Rich Salz's message of "Tue, 21 Oct 2014 22:32:55 -0400")
Message-ID: <87h9ywsbwq.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F94ZjPoz_X2qS23ATgt9_J3p3EY
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 09:15:40 -0000

* Rich Salz:

>> The current fallback-scsv is embarrassing.
>
> You seem to be the only one who thinks this.

I agree with Martin, but I'm not sure yet for whom I consider it
embarrassing.


From nobody Wed Oct 22 03:04:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2094E1A8F42 for ; Wed, 22 Oct 2014 03:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wl3_-BO4yN9B for ; Wed, 22 Oct 2014 03:04:35 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3571A038E for ; Wed, 22 Oct 2014 03:04:34 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id q1so2590144lam.36 for ; Wed, 22 Oct 2014 03:04:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=gXra75ws/auwwjlgIxQnCUwGeeAl6w78pXV7y5+6AMo=; b=fRuzjSSrLoOeuMwClkc0TJ1UQAzVrUosREDVsPMv70v9M+UVApQm1H0xeORdmq2t1G rtBowskKt5eNh8G7kh9cVqQPj1uygHBWlUB4Y45vNSROqJCttOaxgM3DR3xoh0scz5fi 3BrHFzHTJjGgWWVAayS6GJHp39H0lCOqe+lPrcrjkZwe+YUHfkrGv6Evy/UAFDxG2WL5 +gZ0i/Wekxyll+VRoA54onE/8PZE2s9pqb1CkDhPPwjYokebHMZRy5ItcTQaKr4bhUK0 XmmbTAfBpRW+7b5LnM1my7IJDlwWWBemcwtY+chtKKTDdFpxeR7/1yxfO1k4OqTjNBvy KjoA==
MIME-Version: 1.0
X-Received: by 10.113.5.7 with SMTP id ci7mr41413384lbd.9.1413972273062; Wed, 22 Oct 2014 03:04:33 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Wed, 22 Oct 2014 03:04:33 -0700 (PDT)
Date: Wed, 22 Oct 2014 03:04:33 -0700
Message-ID: 
From: Martin Thomson 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8ErjasEXfWIpKtQoGLogc51kLjU
Subject: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 10:04:37 -0000

The update proposal that ekr sent around was discussed.

The primary concern was that the properties of the connection were
considered to change with respect to authentication.  Any data
received before the authentication, or messages that appear partially
before and partially after would have ambiguous properties.

Concerns were raised that having the authentication attest to data
that was sent prior to the authentication would expose us to a variety
of attacks that relied on confusion about the state of the connection.
There was also a concern that this would be difficult to analyse.

It was pointed out that update was still interesting, but only from a
rekeying perspective, because that had far lesser risks and no real
API implications.

If we decided to continue with Update, then we would have a place to
add a future extension that re-enabled this feature.

I noted that the use case that renegotiation provides was not going to
be supported with the proposed Update message, since there was no
analogue for the HelloRequest message.

All of this led to the decision not to pursue spontaneous authentication.


From nobody Wed Oct 22 05:07:40 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA4E1A900A for ; Wed, 22 Oct 2014 05:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0Vx28tnaA0a for ; Wed, 22 Oct 2014 05:07:31 -0700 (PDT)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FE11A8F3C for ; Wed, 22 Oct 2014 05:07:30 -0700 (PDT)
Received: by mail-la0-f53.google.com with SMTP id gq15so2729529lab.26 for ; Wed, 22 Oct 2014 05:07:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jgrsdPKopP5Pez9XymFFh1m1pbFUtWsdOx5itOxbKVs=; b=zyOwxXWJn9Jw5zHGysKn5ABHDKdtB7m5mH1qDOVMBx6EtMpmO0gqnL32D9GsFhOlRq k4ejqfAW/XHuSVLoK+YIFIDWLFCi9kmhP3+Uke+gk3D2IHpxX6E05SyZuy5Yy8QzEnr5 px/34D9mVyyTDTY15pHFGNbneL7sIEzx+QrNu0c/IroKJXCzbgi3fFcKVkLquwAGtKYJ 9rSqXZiWJLRb5CuPEjJ1625zCb7jggJ8AtxzXTZoHePvVpnSuzPljPhlHMvCNtHKMB5J NQ0hJ6Rx1Ao43a9gdUACPZSRv3uIhnAduH9OLduXJgKWMwXvnh95UCuRq4G55zaf2hrP czHw==
MIME-Version: 1.0
X-Received: by 10.152.27.38 with SMTP id q6mr2542550lag.92.1413979649214; Wed, 22 Oct 2014 05:07:29 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Wed, 22 Oct 2014 05:07:29 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 22 Oct 2014 05:07:29 -0700
Message-ID: 
From: Martin Thomson 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8WCvHCIR2_6Zd_zNtYwNpjPME0U
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 12:07:33 -0000

I forgot one point that we discussed.

We discussed the removal of the CertificateRequest and we will permit
the client to unilaterally send authentication.

The theory here is that clients tend to know whether they need to
authenticate.  Most uses of mutual authentication start with the
client knowing that they need to authenticate.  Anything more
complicated will require some application protocol signals.

This also avoids the deficiencies with CertificateRequest, allowing -
or requiring - application protocols to provide equivalent
functionality if that is desired (see my -cant proposal for one
potential way to do that).

On 22 October 2014 03:04, Martin Thomson  wrote:
> The update proposal that ekr sent around was discussed.
>
> The primary concern was that the properties of the connection were
> considered to change with respect to authentication.  Any data
> received before the authentication, or messages that appear partially
> before and partially after would have ambiguous properties.
>
> Concerns were raised that having the authentication attest to data
> that was sent prior to the authentication would expose us to a variety
> of attacks that relied on confusion about the state of the connection.
> There was also a concern that this would be difficult to analyse.
>
> It was pointed out that update was still interesting, but only from a
> rekeying perspective, because that had far lesser risks and no real
> API implications.
>
> If we decided to continue with Update, then we would have a place to
> add a future extension that re-enabled this feature.
>
> I noted that the use case that renegotiation provides was not going to
> be supported with the proposed Update message, since there was no
> analogue for the HelloRequest message.
>
> All of this led to the decision not to pursue spontaneous authentication.


From nobody Wed Oct 22 05:51:27 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7B11A90F3 for ; Wed, 22 Oct 2014 05:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT1FKLtjswKT for ; Wed, 22 Oct 2014 05:51:23 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD0A1A90F8 for ; Wed, 22 Oct 2014 05:51:23 -0700 (PDT)
Received: by mail-ig0-f172.google.com with SMTP id r2so796160igi.17 for ; Wed, 22 Oct 2014 05:51:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iED+OGnGCPMOIpzYPTM4VS2GX0QYIVl0s8Fmf+BlSw0=; b=wZnAzEb4ZHjgOUAkX3AeV4bq6tUvfahTk1YEpEepdbksTvqMrI6ueUOB9R6d53BIvN rPdirccKiZIIVqFYwQdrefXSXGDWr28+/Bh265WD0d7Yw2ewW2TsLgFyVo9w+OhO18dx aIBBZm+mC3EPxHMNO5i1nBoMeUhMNHSW2+dp0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iED+OGnGCPMOIpzYPTM4VS2GX0QYIVl0s8Fmf+BlSw0=; b=cUdEUUj2OncJhfSJzQoFzLat/At128F1lWCTraDEyH75EZ6pxzqEu9/o/EhJf0WGPO P2zny2N1tbQblQrdS1v+I1PC2lPe1h43H+FhzTQuFiJd+AZk1+RZ836VZcjlh5ogVYaX 4DsVsK3krV4uTT6C1R5mvU/0rJBkGmUmrAEriahj82zvzsYpOcn1XSu+uDWaYkPAHy/w rH4JSwzLnCl8MkmhGGxPC0kezkLGAZqxF6peD9eJRrCNXeaxCBsfU6z+GsH9DkY8kwNR jSaELciM9AT865oWgJ/v2gCrRD3yeo2NdUrp208l1jEOshGqKUw4kexHGOmIUBe4pNvf 12ww==
X-Gm-Message-State: ALoCoQkLpQRUSxChgiO+Uig/0CsdRVmE1Q3OwVdDKLrtPT2wwqy51OienqgvdI764XhO/Ys6uLmf
MIME-Version: 1.0
X-Received: by 10.107.137.36 with SMTP id l36mr2426863iod.61.1413982282609; Wed, 22 Oct 2014 05:51:22 -0700 (PDT)
Received: by 10.107.17.15 with HTTP; Wed, 22 Oct 2014 05:51:22 -0700 (PDT)
Received: by 10.107.17.15 with HTTP; Wed, 22 Oct 2014 05:51:22 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 22 Oct 2014 08:51:22 -0400
Message-ID: 
From: Tom Ritter 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=001a113ed040ac92b3050602677a
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/An7ShSeXLBNeWxIrmkyf6cVtlFI
Cc: tls@ietf.org
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 12:51:25 -0000

--001a113ed040ac92b3050602677a
Content-Type: text/plain; charset=ISO-8859-1

On Oct 22, 2014 8:07 AM, "Martin Thomson"  wrote:
>
> I forgot one point that we discussed.
>
> We discussed the removal of the CertificateRequest and we will permit
> the client to unilaterally send authentication.

Will permit it to be absent, or will remove CertificateRequest entirely?

> The theory here is that clients tend to know whether they need to
> authenticate.  Most uses of mutual authentication start with the
> client knowing that they need to authenticate.

Well, the human knows he needs a client certificate for this website, the
Browser does not unless it stores that information. (And still needs to
learn it for first connect)

If CertificateRequest is being removed, it's not clear to me how a browser
would know to include a client cert. An alert and reconnect?  (For other
applications like VPNs, obviously much easier to solve.)

-tom

--001a113ed040ac92b3050602677a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Oct 22, 2014 8:07 AM, "Martin Thomson" <martin.thomson@gmail.com> wr=
ote:

>

> I forgot one point that we discussed.

>

> We discussed the removal of the CertificateRequest and we will permit<=
br>
> the client to unilaterally send authentication.


Will permit it to be absent, or will remove CertificateReque=
st entirely?


> The theory here is that clients tend to know whether th=
ey need to

> authenticate.=A0 Most uses of mutual authentication start with the

> client knowing that they need to authenticate.=A0 


Well, the human knows he needs a client certificate for this=
 website, the Browser does not unless it stores that information. (And stil=
l needs to learn it for first connect)


If CertificateRequest is being removed, it's not clear t=
o me how a browser would know to include a client cert. An alert and reconn=
ect?=A0 (For other applications like VPNs, obviously much easier to solve.)=



-tom




--001a113ed040ac92b3050602677a--


From nobody Wed Oct 22 05:54:05 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4510D1A8BC4 for ; Wed, 22 Oct 2014 05:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17ND5pYcu6sd for ; Wed, 22 Oct 2014 05:54:02 -0700 (PDT)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22C81A8AFE for ; Wed, 22 Oct 2014 05:54:01 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 793FB1887AC; Wed, 22 Oct 2014 15:53:59 +0300 (EEST)
Date: Wed, 22 Oct 2014 15:53:59 +0300
From: Ilari Liusvaara 
To: Martin Thomson 
Message-ID: <20141022125359.GA18704@LK-Perkele-VII>
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PdNyW-uwN0CirHdyoLrnnJM-Jq4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 12:54:04 -0000

On Wed, Oct 22, 2014 at 05:07:29AM -0700, Martin Thomson wrote:
> I forgot one point that we discussed.
> 
> We discussed the removal of the CertificateRequest and we will permit
> the client to unilaterally send authentication.

CertificateRequest has fields certificate_types and
supported_signature_algorithms (there's also third field, but IMO
that's better sent at application level). Where is the equivalent
data put?
 
> On 22 October 2014 03:04, Martin Thomson  wrote:
> > The update proposal that ekr sent around was discussed.
> >
> > The primary concern was that the properties of the connection were
> > considered to change with respect to authentication.  Any data
> > received before the authentication, or messages that appear partially
> > before and partially after would have ambiguous properties.
> >
> > Concerns were raised that having the authentication attest to data
> > that was sent prior to the authentication would expose us to a variety
> > of attacks that relied on confusion about the state of the connection.
> > There was also a concern that this would be difficult to analyse.

The behaviour of authentication credentials being updated mid-connection
is highly application-dependent.

In practicular, any application protocol wanting to support such thing
needs to carefully specify, in race-free way, what authority applies
to each piece of data.

So client doesn't send piece of data, thinking it is using authority A,
but server goes and interprets it using authority B.

And for some applications, one wants to be possible to have multiple
authentications at once.

Client and server being confused about authority results in security
holes. And those holes are being exploited in the wild.

> > It was pointed out that update was still interesting, but only from a
> > rekeying perspective, because that had far lesser risks and no real
> > API implications.

Note that rekeying interacts with TLS-EXTRACTOR, which is part of API.

In practicular, how to avoid race conditions between key update and
use of TLS-EXTRACTOR output?


-Ilari


From nobody Wed Oct 22 05:57:15 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861731A8AFE for ; Wed, 22 Oct 2014 05:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKPVqf8QOmAq for ; Wed, 22 Oct 2014 05:57:08 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D24E1A90F6 for ; Wed, 22 Oct 2014 05:57:08 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9MCujKH015522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 22 Oct 2014 08:56:46 -0400
Received: from pintsize.usersys.redhat.com (vpn1-7-116.ams2.redhat.com [10.36.7.116]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9MCufBc027308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2014 08:56:43 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Wed, 22 Oct 2014 14:56:40 +0200
Message-ID: <1659862.HPNNz8lRhl@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <544606E5.2070807@fussenegger.info> 
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YuqsYC_wrkElnNtuens_VE-9zRg
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 12:57:12 -0000

On Tuesday 21 October 2014 14:33:43 David Leon Gil wrote:
> On Tue, Oct 21, 2014 at 3:10 AM, Richard Fussenegger, BSc
> 
>  wrote:
> > I'm [. . .] glimpsing over to the fact that the
> > cryptography community agrees that 128 bit security will be enough for the
> > next 10 to 20 years.[2]
> 
> This really isn't true. See djb's "matching AES security" at
> https://www.ietf.org/mail-archive/web/cfrg/current/msg04820.html
> 
> Summarizing: The workfactor of a multi-target attack is much lower for
> symmetric-key crypto than for attacks against asymmetric-key crypto.
> This is exactly the sort of attack that is useful for mass
> surveillance.
> 
> We need to start moving away from AES-128 now, not in 10 years.
> 
> (Note that a number of cryptographers think that 2^90 operations per
> year is feasible today; djb is lowballing the number a bit.)

That assumes that you have the space to store all those communications, most 
of which will be utter garbage for you (spdy/HTTP2.0 as a whole and HTTP1.1 
keep alive connections), then you need to have the ability to reference all 
those 2^50 keys in close to real time.

Yes, it doesn't require "hard" computation, but it does require massive 
amounts of relatively fast memory.

It's a classic memory-time tradeoff, isn't it?

And looking at current computers, time is cheaper and is getting cheaper 
faster than memory is, as it has for at least past 20 years...

-- 
Regards,
Hubert Kario


From nobody Wed Oct 22 06:06:52 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2191A8AFE for ; Wed, 22 Oct 2014 06:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.747
X-Spam-Level: 
X-Spam-Status: No, score=0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_FR=0.35, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycIAyqlnh8lY for ; Wed, 22 Oct 2014 06:06:49 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1371A9119 for ; Wed, 22 Oct 2014 06:06:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=ouX0gqf9c/rrzoQ50IOeGeD1ZjcEWvRp6szfbF8jumg=;  b=bdPR28G+85TI5ZRbU7yKIZ0LQ77BzWuhRFPuNe57jHnfrR+/zxJYYuxF+02h+IMdX2E8V5h7JPi+nsh4ZmWgl/9V3nIccSGGOGeFIRaZBDeCMc7e4KAnG8HZ6to6PA9lhju2JK5XppWmyErY1QNY8Ofk7U/Ckn0V1wrO7+FMkYU=;
Received: from guest-rocq-135165.inria.fr ([128.93.135.165]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgvcU-00078x-3k; Wed, 22 Oct 2014 15:06:30 +0200
Message-ID: <5447ABD5.7020402@polarssl.org>
Date: Wed, 22 Oct 2014 15:06:29 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Tom Ritter , Martin Thomson 
References:   
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 128.93.135.165
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sbT603b7jeU31HzUfV0SEg4PqjI
Cc: tls@ietf.org
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 13:06:50 -0000

On 22/10/2014 14:51, Tom Ritter wrote:
> On Oct 22, 2014 8:07 AM, "Martin Thomson"  wrote:
>>
>> I forgot one point that we discussed.
>>
>> We discussed the removal of the CertificateRequest and we will permit
>> the client to unilaterally send authentication.
> 
> Will permit it to be absent, or will remove CertificateRequest entirely?
> 
My understanding is it would be entirely removed.

>> The theory here is that clients tend to know whether they need to
>> authenticate.  Most uses of mutual authentication start with the
>> client knowing that they need to authenticate.
> 
> Well, the human knows he needs a client certificate for this website, the
> Browser does not unless it stores that information. (And still needs to
> learn it for first connect)
> 
> If CertificateRequest is being removed, it's not clear to me how a browser
> would know to include a client cert. An alert and reconnect?  (For other
> applications like VPNs, obviously much easier to solve.)
>
That would be moved to the application layer, eg for HTTP(bis) that would be
addressed by Martin's "cant" draft as he briefly mentioned:
https://tools.ietf.org/html/draft-thomson-httpbis-cant-01

Manuel.


From nobody Wed Oct 22 06:08:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7748A1A90DC for ; Wed, 22 Oct 2014 06:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KncVoxrkz6fj for ; Wed, 22 Oct 2014 06:08:19 -0700 (PDT)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23FD41A90F7 for ; Wed, 22 Oct 2014 06:08:18 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id l4so2852210lbv.12 for ; Wed, 22 Oct 2014 06:08:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mim96bhkeDt7uV5fNl196EVoDAbV/hvUDQvmvQkpghY=; b=niXbvvK0V/lIMOeg3k1k5j43LenDrJPi0H6ZFdxTKvdgDZMb0ZTlFKwrkcTEeCtHso cUhIJUcKM8K3exRvdEzvP7Cke2IcLYnIsto2O5BFXQfhH7XCdxEMcMNRdvCWibkPBfuN oy0X1jH4y2hiVsjeMR6zPHxQf7cOIq5g/scc+YS5TayjhFBWHZnUpfMXFW1hQV8ipBFR jR9skDpsF/91lfNf0hLC45o7nxSkRFzNq5bOCfCwD+5GaurY1MvjgeWOaPgpNKVjVkUX bm8d3OM/rTNFCathZHDitfq14AZbBrrlko3wOADTuAdDMfNLDWz4Bd4BHBia92VPyiQt 0MRA==
MIME-Version: 1.0
X-Received: by 10.152.23.3 with SMTP id i3mr17437832laf.53.1413983297382; Wed, 22 Oct 2014 06:08:17 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Wed, 22 Oct 2014 06:08:17 -0700 (PDT)
In-Reply-To: <20141022125359.GA18704@LK-Perkele-VII>
References:   <20141022125359.GA18704@LK-Perkele-VII>
Date: Wed, 22 Oct 2014 06:08:17 -0700
Message-ID: 
From: Martin Thomson 
To: Ilari Liusvaara 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2LfYyO430oparVL3Pfd-qGj08VA
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 13:08:21 -0000

On 22 October 2014 05:53, Ilari Liusvaara  wrote:
>
> CertificateRequest has fields certificate_types and
> supported_signature_algorithms (there's also third field, but IMO
> that's better sent at application level). Where is the equivalent
> data put?

At the application layer.

These fields, as specified, are not particularly useful in the general
sense.  The suggestion was that these are not valuable:
certificate_types is pretty much either known a priori (or assumed to
be X.509) and signatures have a similarly limited set of options.


From nobody Wed Oct 22 06:26:31 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA041A913D for ; Wed, 22 Oct 2014 06:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TotQKbKKVJL0 for ; Wed, 22 Oct 2014 06:26:26 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2CB1A9131 for ; Wed, 22 Oct 2014 06:26:26 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id B57D51A2674; Wed, 22 Oct 2014 16:26:23 +0300 (EEST)
Date: Wed, 22 Oct 2014 16:26:23 +0300
From: Ilari Liusvaara 
To: Martin Thomson 
Message-ID: <20141022132623.GA19894@LK-Perkele-VII>
References:   <20141022125359.GA18704@LK-Perkele-VII> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0v6eibj2ajlWs2-vOp9NU14oPPc
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 13:26:28 -0000

On Wed, Oct 22, 2014 at 06:08:17AM -0700, Martin Thomson wrote:
> On 22 October 2014 05:53, Ilari Liusvaara  wrote:
> >
> > CertificateRequest has fields certificate_types and
> > supported_signature_algorithms (there's also third field, but IMO
> > that's better sent at application level). Where is the equivalent
> > data put?
> 
> At the application layer.
> 
> These fields, as specified, are not particularly useful in the general
> sense.  The suggestion was that these are not valuable:
> certificate_types is pretty much either known a priori (or assumed to
> be X.509) and signatures have a similarly limited set of options.

Don't confuse certificate_types with {client,server}_certificate_type{,s}.

The relevant values of certificate_types look to be:
- rsa_sign (RSA signature)
- dss_sign (DSA signature)
- ecdsa_sign (ECDSA signature)

(There are some others, but all are either RESERVED or obviously
incompatible with TLS 1.3).


supported_signature_algorithms looks to be supported combinations
of signature (RSA/DSA/ECDSA) and hash.


Especially supported_signature_algorithms looks to belong to TLS
layer (and also arguably certificate_types).


Now, the "third field" was certificate_authorities. Now that is
better sent on application layer.


-Ilari


From nobody Wed Oct 22 07:28:18 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3E31ACCE3 for ; Wed, 22 Oct 2014 07:28:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPFkmLZJlvPQ for ; Wed, 22 Oct 2014 07:28:11 -0700 (PDT)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039881ACCDF for ; Wed, 22 Oct 2014 07:27:55 -0700 (PDT)
Received: by mail-lb0-f170.google.com with SMTP id u10so2974610lbd.15 for ; Wed, 22 Oct 2014 07:27:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=y17wkwrL4WToBRKXy8yAp3ZbueBybKyx8PMmplrAZ6U=; b=pmll8Wt4ndhWcA9RbPPlhQJI//qIwlKKyQYiUjpFMq94HNWgYVFUiRb6Y7ysVweUlo BsqLtVvIQ2It7bLMn/FAEqAvqo93Jdw2T2ZkTTw8MxEz6qTKsXPE2ziU1v9nk0267bKI d8yUdshyUGZsRtvK+1Q9e5nMMLis+TDbUv97l9iTjWl5fTtSwicgxDF9Zwh7r/niRVSi 7qeIHpE7Ka6I7vsymoWmXSbCMqB2mvhwcv003kQJehDqz4J/BkVCOuWh3GLIkOBPb7Mv GyS9rjT9snxTjL/Xhcyjhv2Y+sygw59bcFAhTzzIv1LSOiJ8Zg+JBzXgZVBAB2nsnoJD ns1w==
X-Received: by 10.112.11.201 with SMTP id s9mr23735757lbb.79.1413988074193; Wed, 22 Oct 2014 07:27:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.218.145 with HTTP; Wed, 22 Oct 2014 07:27:32 -0700 (PDT)
In-Reply-To: <1659862.HPNNz8lRhl@pintsize.usersys.redhat.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <544606E5.2070807@fussenegger.info>  <1659862.HPNNz8lRhl@pintsize.usersys.redhat.com>
From: David Leon Gil 
Date: Wed, 22 Oct 2014 10:27:32 -0400
Message-ID: 
To: Hubert Kario 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lG2QyHDvLOvuV_NoRWS2WOYkvCA
Cc: tls@ietf.org
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 14:28:14 -0000

There are, obviously, two things a server should be able to use for a
unified session id/ticket:

 - An opaque identifier
 - Encrypted session state using a construction like RFC 5077's.

Right now, RFC 5077 recommends: AES-128 with a 128-bit key and
HMAC-SHA256 with a 256-bit key.

Or, uselessly high 256-bit security against active attackers, and
uselessly low 128-bit security strength against global passive
adversaries.

There should be a recommended session ticket construction at a 256 bit
security strength for privacy to replace RFC 5077 s.4's.

--

On Wed, Oct 22, 2014 at 8:56 AM, Hubert Kario  wrote:
> That assumes that you have the space to store all those communications,

I frankly don't understand this.

According to the newspapers, at least, the NSA *does* store *all*
encrypted communications pending eventual decryption. So evidently
they do, at least.

> then you need to have the ability to reference all those 2^50 keys in close to real time.

This is a few petabytes of data, or a few thousand 1 TB SSDs. This is
not a large amount of data.

> Yes, it doesn't require "hard" computation, but it does require massive
> amounts of relatively fast memory.

No. It doesn't. It requires less than one cipher block per key for
most of the computation. (The main expense is memory bandwidth.)

> It's a classic memory-time tradeoff, isn't it?

No. The gains are better than linear. See
http://cr.yp.to/snuffle/bruteforce-20050425.pdf, but for "circuit"
read "graphics card/SPU/MIC".


From nobody Wed Oct 22 07:29:30 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B911AC429 for ; Wed, 22 Oct 2014 07:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAE5VX81U7KL for ; Wed, 22 Oct 2014 07:29:23 -0700 (PDT)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074461ACC88 for ; Wed, 22 Oct 2014 07:29:22 -0700 (PDT)
Received: by mail-lb0-f178.google.com with SMTP id w7so2966226lbi.9 for ; Wed, 22 Oct 2014 07:29:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BeSgwO4m515XlkYPi2gBEIwA6yav5lfDR86jgof8ewM=; b=hupP5zaSQ2vSXo0Fc3Mi6pbTGog//1u5twMPsRwBIvAage9Ar2W6p1nETEodu/j4SP sCXB2UZyyx3NGWwI049Zjz3RncSGF+kLMKcTwK+Ebwc8paVtO0tjqYvHhC1rFNQ8ppS5 5XHkqcKik4BPA1TmWehBWwabshN3cjnwgkBNTXpbeMRuSa0k9VhCtM/3Ke3xSOvLvm6z rrmsrzAYGSFaIAJtUI9P5FEqc3y1MWb3mSKuaG9AgeJDd/rnEnUGwUBK7n4cqI6yxLQa HFegl9959BZP50GTG9pxetVbboAxh6DQaip9f2rbRMf44QhENb1L6cOEgMMxF/IO2Bzo eMuA==
MIME-Version: 1.0
X-Received: by 10.112.132.104 with SMTP id ot8mr41898301lbb.3.1413988161334; Wed, 22 Oct 2014 07:29:21 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Wed, 22 Oct 2014 07:29:21 -0700 (PDT)
In-Reply-To: <20141022132623.GA19894@LK-Perkele-VII>
References:   <20141022125359.GA18704@LK-Perkele-VII>  <20141022132623.GA19894@LK-Perkele-VII>
Date: Wed, 22 Oct 2014 07:29:21 -0700
Message-ID: 
From: Martin Thomson 
To: Ilari Liusvaara 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NXck2I0XTtyJ3rLuymVJrWRCW2Y
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 14:29:27 -0000

On 22 October 2014 06:26, Ilari Liusvaara  wrote:
> Don't confuse certificate_types with {client,server}_certificate_type{,s}.

The claim was that this is either known, period, or can be pushed to
the application layer.  Fact is, what we have is this:

Clients have one or zero certificates for a given server and will use
that regardless of what appears in the CertificateRequest.

Servers have one or zero certificates for each name they offer and
will use that no matter what.

I tend to think that we need a more general mechanism for indicating
support for certificate types and signature algorithms.  Maybe we
could unconditionally include those in the early handshake instead.


From nobody Wed Oct 22 07:31:09 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27581AC41D for ; Wed, 22 Oct 2014 07:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.747
X-Spam-Level: 
X-Spam-Status: No, score=0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_FR=0.35, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esLE4yP0OR8l for ; Wed, 22 Oct 2014 07:31:06 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6231AC3E6 for ; Wed, 22 Oct 2014 07:31:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=ci/WWmT97vwKrSh4tPIee4nV1ipgLZ8O3BgjQI5nGPo=;  b=PPBKEyBwqMuRYzVWIypEKGwxDZG1t/3+WmxxiAMIMyewc1tZ0lqU/uio8GNhWDrQ70izZ3Oly89D34R1nyqypBq3mNuPPYO2W0q+bAZOwUH8MKUswNKVvc8oVhCdCWN251faAFrBABG1WfSrup1ootdx49DShz/V5Z97yXhkWZo=;
Received: from guest-rocq-135165.inria.fr ([128.93.135.165]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgwwE-0007FM-SW; Wed, 22 Oct 2014 16:30:59 +0200
Message-ID: <5447BFA2.3030007@polarssl.org>
Date: Wed, 22 Oct 2014 16:30:58 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ilari Liusvaara ,  Martin Thomson 
References:   <20141022125359.GA18704@LK-Perkele-VII>  <20141022132623.GA19894@LK-Perkele-VII>
In-Reply-To: <20141022132623.GA19894@LK-Perkele-VII>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 128.93.135.165
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EaKCwXG9hUqgoAF9Bb2WM-ZftPU
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 14:31:06 -0000

On 22/10/2014 15:26, Ilari Liusvaara wrote:
> The relevant values of certificate_types look to be:
> - rsa_sign (RSA signature)
> - dss_sign (DSA signature)
> - ecdsa_sign (ECDSA signature)
> 
I think the point is, a client is actually quite unlikely to have many
certificates for the same server, distinguished only by the key type, so that
this information is generally not useful at all for certificate selection.

> Especially supported_signature_algorithms looks to belong to TLS
> layer (and also arguably certificate_types).
> 
Same as above.

Manuel.


From nobody Wed Oct 22 07:31:46 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB43B1ACCEB for ; Wed, 22 Oct 2014 07:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ifz2zs9MZN5 for ; Wed, 22 Oct 2014 07:31:40 -0700 (PDT)
Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B06B1ACCE8 for ; Wed, 22 Oct 2014 07:31:40 -0700 (PDT)
Received: by mail-yh0-f54.google.com with SMTP id 29so3941871yhl.27 for ; Wed, 22 Oct 2014 07:31:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DTV/qYFdGCdv6dfJVEyisEMTnB/MEA3PiMjFYXO4oW0=; b=t3JaCzweItFImefA3SLZ5sE5D7FtmttBz6RKbhOLHekQMbaieZ993hpqxgR/zmloun OxbPh39L6VdAnM8fH0v/1R14n+xCoYfsxBR43eTcVN7YVabrJowih6bB3fJ/oWvA+V1u 5A/yU3v5cUHWG8k30yiSTxyg8RqFxeJrQ5PrzIJsO2OxU2KTvI1ktXv4zZsjJXY1Vfug bxArbppJWtGKpxWxD0AgijmlpzUrzFBVwqrJTngEK/1z030ZVMjeok5w9LoC6zge588A tA2KX3gXHQ2t3ymh3FMwdyrV8sEvckKgUeKWZSgqhIWCTJNasAvUOx67Zt464OsmrzkX ehOg==
MIME-Version: 1.0
X-Received: by 10.236.17.197 with SMTP id j45mr58909744yhj.49.1413988299732; Wed, 22 Oct 2014 07:31:39 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Wed, 22 Oct 2014 07:31:39 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 22 Oct 2014 07:31:39 -0700
Message-ID: 
From: Watson Ladd 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6eI3IeZgVJCUGKCZEcp_llYDHk4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 14:31:42 -0000

On Wed, Oct 22, 2014 at 3:04 AM, Martin Thomson
 wrote:
> The update proposal that ekr sent around was discussed.
>
> The primary concern was that the properties of the connection were
> considered to change with respect to authentication.  Any data
> received before the authentication, or messages that appear partially
> before and partially after would have ambiguous properties.

Why is the proposal worse than fixed renegotiation in this regard? I
agree, it's possible to simplify a lot by forcing reconnection to
authenticate, but it isn't necessary to do so.

>
> Concerns were raised that having the authentication attest to data
> that was sent prior to the authentication would expose us to a variety
> of attacks that relied on confusion about the state of the connection.
> There was also a concern that this would be difficult to analyse.
>
> It was pointed out that update was still interesting, but only from a
> rekeying perspective, because that had far lesser risks and no real
> API implications.
>
> If we decided to continue with Update, then we would have a place to
> add a future extension that re-enabled this feature.
>
> I noted that the use case that renegotiation provides was not going to
> be supported with the proposed Update message, since there was no
> analogue for the HelloRequest message.

As far as I can tell, not true with regard to HTTP. I believe (but may
be wrong) that when a client is informed by a server it needs to
authenticate to make a request, that this is done by an error code,
not sending a HelloRequest message.

>
> All of this led to the decision not to pursue spontaneous authentication.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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


From nobody Wed Oct 22 07:35:06 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7165E1AC3DC for ; Wed, 22 Oct 2014 07:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Imy-yoLrzKCp for ; Wed, 22 Oct 2014 07:35:01 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB071AC40B for ; Wed, 22 Oct 2014 07:35:01 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id y10so3831457wgg.15 for ; Wed, 22 Oct 2014 07:34:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uxqrRqn4awCa2W2CiHqBAYNEQ1JWYtinVuzkBjSX8xo=; b=Jxf/Et62IMgqnfVHr6PSZ12MSIXgZcYAhCgyT9qHXjdfy+61Z5tR4+uywpl6hFkAuj a8Tn7qqwXb8JLIIlrGvKpUESA094s7LXRpb/5Tyy6U6zbiKJFUNxi0+rxtEOPOcBC69W L+izx5ggyhBzk+iY/RKdOAc+e41bEVFhu2VrjQrdZKwokMOhYni9yibqRi8wwc5HX/8n Zqvkm08DnWsqssFWceHl1ecxK/yuORq44fkQMgbZHe7mApYM2JWwX8M7iIB2Yli5th2K 7Ww0zE7raYPcrCPC6oRBH718h66hf/n7ojRb7oOKMjI10Vmyw/Q4Fr0htcE8OnmqUGm2 o8PA==
X-Gm-Message-State: ALoCoQlJvUZruE3m6PWU+NH6A/6Tar8QU9IOFvUiJ3jxqm9Adh67H0V0mbSGnx5rozkvn4+UmU/d
X-Received: by 10.180.103.233 with SMTP id fz9mr37091146wib.80.1413988499773;  Wed, 22 Oct 2014 07:34:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Wed, 22 Oct 2014 07:34:19 -0700 (PDT)
In-Reply-To: 
References:  
From: Eric Rescorla 
Date: Wed, 22 Oct 2014 16:34:19 +0200
Message-ID: 
To: Watson Ladd 
Content-Type: multipart/alternative; boundary=f46d044280ca3f1463050603da8b
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6C1ADw-21efSn7zuKRn6V-dyBzU
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 14:35:03 -0000

--f46d044280ca3f1463050603da8b
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 22, 2014 at 4:31 PM, Watson Ladd  wrote:

> On Wed, Oct 22, 2014 at 3:04 AM, Martin Thomson
>  wrote:
> > The update proposal that ekr sent around was discussed.
> >
> > The primary concern was that the properties of the connection were
> > considered to change with respect to authentication.  Any data
> > received before the authentication, or messages that appear partially
> > before and partially after would have ambiguous properties.
>
> Why is the proposal worse than fixed renegotiation in this regard? I
> agree, it's possible to simplify a lot by forcing reconnection to
> authenticate, but it isn't necessary to do so.
>
> >
> > Concerns were raised that having the authentication attest to data
> > that was sent prior to the authentication would expose us to a variety
> > of attacks that relied on confusion about the state of the connection.
> > There was also a concern that this would be difficult to analyse.
> >
> > It was pointed out that update was still interesting, but only from a
> > rekeying perspective, because that had far lesser risks and no real
> > API implications.
> >
> > If we decided to continue with Update, then we would have a place to
> > add a future extension that re-enabled this feature.
> >
> > I noted that the use case that renegotiation provides was not going to
> > be supported with the proposed Update message, since there was no
> > analogue for the HelloRequest message.
>
> As far as I can tell, not true with regard to HTTP. I believe (but may
> be wrong) that when a client is informed by a server it needs to
> authenticate to make a request, that this is done by an error code,
> not sending a HelloRequest message.


That's correct for RFC 7235 authentication (i.e.. Basic and Digest)
but not for TLS Client Authentication.

-Ekr

--f46d044280ca3f1463050603da8b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 22, 2014 at 4:31 PM, Watson Ladd <watsonbladd@gmail.co=
m> wrote:
=
On Wed, Oct 22, 2014 at 3:04 AM, Martin Thomson

<martin.thomson@gmail.com> wrote:

> The update proposal that ekr sent around was discussed.

>

> The primary concern was that the properties of the connection were

> considered to change with respect to authentication.=C2=A0 Any data
> received before the authentication, or messages that appear partially<=
br>
> before and partially after would have ambiguous properties.



Why is the proposal worse than fixed renegotiation in this regard? I=


agree, it's possible to simplify a lot by forcing reconnection to

authenticate, but it isn't necessary to do so.



>

> Concerns were raised that having the authentication attest to data

> that was sent prior to the authentication would expose us to a variety=


> of attacks that relied on confusion about the state of the connection.=


> There was also a concern that this would be difficult to analyse.

>

> It was pointed out that update was still interesting, but only from a<=
br>
> rekeying perspective, because that had far lesser risks and no real
> API implications.

>

> If we decided to continue with Update, then we would have a place to
> add a future extension that re-enabled this feature.

>

> I noted that the use case that renegotiation provides was not going to=


> be supported with the proposed Update message, since there was no

> analogue for the HelloRequest message.



As far as I can tell, not true with regard to HTTP. I believe (but m=
ay

be wrong) that when a client is informed by a server it needs to

authenticate to make a request, that this is done by an error code,

not sending a HelloRequest message.


<=
div>



--f46d044280ca3f1463050603da8b--


From nobody Wed Oct 22 07:38:06 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8293F1ACC8B for ; Wed, 22 Oct 2014 07:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_S149SCZSQP for ; Wed, 22 Oct 2014 07:37:57 -0700 (PDT)
Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D281ACCED for ; Wed, 22 Oct 2014 07:37:57 -0700 (PDT)
Received: by mail-yh0-f51.google.com with SMTP id t59so3604235yho.10 for ; Wed, 22 Oct 2014 07:37:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tHuOrZDVH7lWigHFalqi5X0kyFSx5g03N/LK28z5gww=; b=Kfc97hXkJzUVYw6+/UugRIBWF/wy+F2BRpnJRUvRdEgiVptd+LQ8gZCVMpRuK/g+jI OXMAEyXQuwhHVpwLGY2iSNvqHr775iZCzjpn5Y46UVgezc1E7gGFulW9ES2tOkVY2CKE qvWDbdlrYZtCEx3WxE42WrvCpAmQbt30Az06kLhOMN5r6yAVnGDZ0cVaI521lVQvQ0U0 Kuhdqy8G8+fH1cfddqCR8b6uuHmA3GDNqjDdwcTI9cov5DEANL7A89axo0qAPZ9tfdqJ Rq9Yob+TBK/8WdO5tRNBgBq/hfr5bqkzTk6RlzLALEFVpUOptXwx9WUd5zvDPxP2mBBE sotQ==
MIME-Version: 1.0
X-Received: by 10.236.7.52 with SMTP id 40mr2757990yho.172.1413988676628; Wed, 22 Oct 2014 07:37:56 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Wed, 22 Oct 2014 07:37:56 -0700 (PDT)
In-Reply-To: 
References:   
Date: Wed, 22 Oct 2014 07:37:56 -0700
Message-ID: 
From: Watson Ladd 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4OKQ0IQ1_RTnY36hAIy9tCSuZ-0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 14:38:05 -0000

On Wed, Oct 22, 2014 at 7:34 AM, Eric Rescorla  wrote:
>
>
> On Wed, Oct 22, 2014 at 4:31 PM, Watson Ladd  wrote:
>>
>> On Wed, Oct 22, 2014 at 3:04 AM, Martin Thomson
>>  wrote:
>> > The update proposal that ekr sent around was discussed.
>> >
>> > The primary concern was that the properties of the connection were
>> > considered to change with respect to authentication.  Any data
>> > received before the authentication, or messages that appear partially
>> > before and partially after would have ambiguous properties.
>>
>> Why is the proposal worse than fixed renegotiation in this regard? I
>> agree, it's possible to simplify a lot by forcing reconnection to
>> authenticate, but it isn't necessary to do so.
>>
>> >
>> > Concerns were raised that having the authentication attest to data
>> > that was sent prior to the authentication would expose us to a variety
>> > of attacks that relied on confusion about the state of the connection.
>> > There was also a concern that this would be difficult to analyse.
>> >
>> > It was pointed out that update was still interesting, but only from a
>> > rekeying perspective, because that had far lesser risks and no real
>> > API implications.
>> >
>> > If we decided to continue with Update, then we would have a place to
>> > add a future extension that re-enabled this feature.
>> >
>> > I noted that the use case that renegotiation provides was not going to
>> > be supported with the proposed Update message, since there was no
>> > analogue for the HelloRequest message.
>>
>> As far as I can tell, not true with regard to HTTP. I believe (but may
>> be wrong) that when a client is informed by a server it needs to
>> authenticate to make a request, that this is done by an error code,
>> not sending a HelloRequest message.
>
>
> That's correct for RFC 7235 authentication (i.e.. Basic and Digest)
> but not for TLS Client Authentication.

So if we want to get rid of changing authentication state in the
middle of a connection, how do we support that?
>
> -Ekr
>
>



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


From nobody Wed Oct 22 07:43:30 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01B41ACC81 for ; Wed, 22 Oct 2014 07:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJHIn9OA5q2I for ; Wed, 22 Oct 2014 07:43:22 -0700 (PDT)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617B31AC41E for ; Wed, 22 Oct 2014 07:43:22 -0700 (PDT)
Received: by mail-la0-f41.google.com with SMTP id pn19so3026014lab.14 for ; Wed, 22 Oct 2014 07:43:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KAQHwuK0lbiI9YsaiTN9tTDRjuJNeLBHQ639GzmkJzw=; b=EHbc82x8jufya5EhdLaQBRk4ZM68gm8NahPH0D18HK/z6md94pTvg3iQnnt3uDH0w0 /iS6LFwFGTl/KCiDaWXMEdQUIijK/dLRFML+q9+sCpbGH43bIfxbdUpQJVZ3blTNYtmf ay034cE65GQ2dMTWsag0+PsqGvQqGYI2XazZ8D3P73gCgvP4oQPCZU2QOr3DrsV4OiFI vnm64B/WKk59iFb1WKgm24lY8FbduMYarYePxkIa3lWiCL7L8lIdKDN3puuysyr2/bqd X0NzmJNMdwoV/iW5gkjlCHeR3/bFlZDHpwVyHsncAMoGyUspG4m9f883lWIW+5HsIl8f uVwQ==
MIME-Version: 1.0
X-Received: by 10.152.216.200 with SMTP id os8mr3470446lac.85.1413989000613; Wed, 22 Oct 2014 07:43:20 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Wed, 22 Oct 2014 07:43:20 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 22 Oct 2014 07:43:20 -0700
Message-ID: 
From: Martin Thomson 
To: Watson Ladd 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ney5rUYCH4Nzui5Ubyy4591TQ8E
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 14:43:26 -0000

On 22 October 2014 07:31, Watson Ladd  wrote:
>> The primary concern was that the properties of the connection were
>> considered to change with respect to authentication.  Any data
>> received before the authentication, or messages that appear partially
>> before and partially after would have ambiguous properties.
>
> Why is the proposal worse than fixed renegotiation in this regard? I
> agree, it's possible to simplify a lot by forcing reconnection to
> authenticate, but it isn't necessary to do so.

The concern wasn't that it was worse than renegotiation: the opposite
in fact because fewer things change.

The concern was that it wasn't appreciably better with respect to the
state of authentication.  And it was more complicated.


>> I noted that the use case that renegotiation provides was not going to
>> be supported with the proposed Update message, since there was no
>> analogue for the HelloRequest message.
>
> As far as I can tell, not true with regard to HTTP. I believe (but may
> be wrong) that when a client is informed by a server it needs to
> authenticate to make a request, that this is done by an error code,
> not sending a HelloRequest message.

That is only a proposal (my -cant thing).  The way this works in
servers today, in TLS 1.2 and earlier is that servers see the request,
identify the need for client authentication and send a HelloRequest.
Once the renegotiation handshake completes and the client has provided
valid credentials, the server sends the response.  In effect, the
authentication is invisible at the HTTP layer, where -cant proposes to
make this explicit.


From nobody Wed Oct 22 07:59:23 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD991ACD40 for ; Wed, 22 Oct 2014 07:59:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBzR1M2Z17BD for ; Wed, 22 Oct 2014 07:59:06 -0700 (PDT)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6F81ACD36 for ; Wed, 22 Oct 2014 07:59:02 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 376B86996E; Wed, 22 Oct 2014 17:59:00 +0300 (EEST)
Date: Wed, 22 Oct 2014 17:59:00 +0300
From: Ilari Liusvaara 
To: Martin Thomson 
Message-ID: <20141022145900.GB21530@LK-Perkele-VII>
References:   <20141022125359.GA18704@LK-Perkele-VII>  <20141022132623.GA19894@LK-Perkele-VII> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0c8l_2qbGTVihqJUXPEflg4zUqU
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 14:59:14 -0000

On Wed, Oct 22, 2014 at 07:29:21AM -0700, Martin Thomson wrote:
> On 22 October 2014 06:26, Ilari Liusvaara  wrote:
> > Don't confuse certificate_types with {client,server}_certificate_type{,s}.
> 
> The claim was that this is either known, period, or can be pushed to
> the application layer.  Fact is, what we have is this:
> 
> Clients have one or zero certificates for a given server and will use
> that regardless of what appears in the CertificateRequest.

That's an argument for pushing certificate_types to application layer,
but not IMO valid argument for supported_signature_algorithms.
 
> I tend to think that we need a more general mechanism for indicating
> support for certificate types and signature algorithms.  Maybe we
> could unconditionally include those in the early handshake instead.

Yeah, agreed. The supported_signature_algorithms could very well
be pushed to ServerHello (or EncryptedExtensions!).

Also, the current supported_signature_algorithms is not quite expressive
enough for ECC. The problem is, there are implementations like:

- ECDSA/SHA-256 is ok when using 256-bit curve.
- ECDSA/SHA-384 is ok when using 384-bit curve.
- Try to use ECDSA/SHA-256 with 384-bit curve or ECDSA/SHA-384 with 256-
  bit curve and things just blow up.

Such implementation would signal ECDSA/SHA-256 and ECDSA/SHA-384 in
supported_signature_algorithms, but that is not the whole story.


-Ilari


From nobody Wed Oct 22 08:16:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2B61ACD4A for ; Wed, 22 Oct 2014 08:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIFRVtU_e15f for ; Wed, 22 Oct 2014 08:16:25 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8794F1ACD43 for ; Wed, 22 Oct 2014 08:16:25 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8D0912AB24B; Wed, 22 Oct 2014 15:16:23 +0000 (UTC)
Date: Wed, 22 Oct 2014 15:16:23 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141022151623.GA19158@mournblade.imrryr.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <544606E5.2070807@fussenegger.info>  <1659862.HPNNz8lRhl@pintsize.usersys.redhat.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WIJJ-wIk1DWWa0ffyx5hfuYgfcs
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 15:16:29 -0000

On Wed, Oct 22, 2014 at 10:27:32AM -0400, David Leon Gil wrote:

> There are, obviously, two things a server should be able to use for a
> unified session id/ticket:
> 
>  - An opaque identifier
>  - Encrypted session state using a construction like RFC 5077's.
> 
> Right now, RFC 5077 recommends: AES-128 with a 128-bit key and
> HMAC-SHA256 with a 256-bit key.
> 
> Or, uselessly high 256-bit security against active attackers, and
> uselessly low 128-bit security strength against global passive
> adversaries.
> 
> There should be a recommended session ticket construction at a 256 bit
> security strength for privacy to replace RFC 5077 s.4's.

The same construction works just fine with AES-256-CBC, so it is
merely a matter of updating the draft to recommend AES-256-CBC for
the encryption.  (I've updated the Postfix default ticket cipher
to AES-256-CBC as planned for the next release).

Mind you, I would not call AES-128-CBC "uselessly low".  Assume
classical attacks, and suppose circuitry running at 1W power-draw
with 2^16 parallel AES units, each of which does 2^32 AES-128
encryptions per second.  The total energy requirement for an AES-128
brute force attack is then:

	(2^128 / 2^16 / 2^32) J = 2^80 J

If this is powered by a sizeable ~4 GW (2^32 W) power plant, it
will take 2^48 seconds to generate the requisite energy.  With
somewhat less than 2^25 seconds per year, we're looking at ~2^23
or ~8 million years of output from such a plant.

If we assume attacks that reduce AES from 128 to 120 bits, that
number comes down to a "mere" 2^15 or 32K years of 4GW power.  The
energy cost is prohibitive, and we've not taken into account the
costs of storage if this is to be a pre-computation for a space-time
trade-off to attack multiple encrypted payloads.

And all this ignores the fact that AES is rarely used in ECB mode
with the same fixed plaintext encrypted by all parties under varying
keys.  The use of random IVs or similar "whitening" makes
pre-computation substantially less effective.

-- 
	Viktor.


From nobody Wed Oct 22 08:19:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E596E1ACD6A for ; Wed, 22 Oct 2014 08:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Level: 
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMOLmcoocwdi for ; Wed, 22 Oct 2014 08:19:09 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A75A1ACD51 for ; Wed, 22 Oct 2014 08:18:21 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 5758172077; Wed, 22 Oct 2014 17:18:19 +0200 (CEST)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 4F2E34227D; Wed, 22 Oct 2014 17:18:19 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 44A791AF05; Wed, 22 Oct 2014 17:18:19 +0200 (CEST)
In-Reply-To: 
To: Martin Thomson 
Date: Wed, 22 Oct 2014 17:18:19 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141022151819.44A791AF05@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bocXKQeqKtuRNDoKKT89dZ1okGQ
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 15:19:14 -0000

Martin Thomson wrote:
> 
> We discussed the removal of the CertificateRequest and we will permit
> the client to unilaterally send authentication.
> 
> The theory here is that clients tend to know whether they need to
> authenticate.

This looks like a bad idea to me.
The by far most important information in the current CertificateRequest
handshake message is the "certification_authorities" field, which indicates
certificate issuers which the server considers acceptable.
In SSLv3 and TLSv1.0 the certificate_authorities field was required
to be non-empty and no (server) behaviour was defined for the meaning
of an empty certification_authorities field in CertificateRequest.

The TLSv1.1 and TLSv1.2 specification contain a defect in that they
modified the PDU definition to allow an empty certification_authorities
field in CertificateRequest, but failed to define (require) a server
behaviour when the server does not send this information.
Without the requirement, that the serer MUST NOT abort the TLS handshake
when sending an empty certificate_authorities and receiving a certificate
which it does not trust, the use of an empty certificate_authorities
field does not make sense.


With recent versions of Lync, Microsoft seems to automatically create a
Lync-specific "SSL client identity" that works for nothing but Lync, but
will successfully interfere with SSL client credentials selections when
browsers are using an SSL client identity for accessing regular Web sites.

To make SSL client certificate authentication work reasonably
a CertificateRequest that conveys acceptable certificate_authorities
for the specific handshake is absolutely necessary.

Apple Safari seems to be notoriously broken when it comes to SSL client
certificate selection, because it fails to process the certificate_authorities
field from a CertificateRequest handshake message and remove obviously
unacceptable certs from the list of credentials that the user is
presented to select from.   I've had customers report connection
failures to our AppServers, and from the server-side error messages
I could see that the client was trying to connect with some appleid
certificate that our server didn't trust (and certainly never announced
in the CertificateRequest.certificate_authorities field.

Microsoft had a similar problem in WinHTTP in 2005
http://support.microsoft.com/kb/909425/en

After WinHTTP was fixed to provide the necessary information
to application callers, it is still necessary for application callers
to actually _use_ that information to select only acceptable certificates,
and that seems to take years to happen.
This is the fix for Office/WebDAV:
http://support.microsoft.com/kb/2647954/en

And Apple Safari 4 Windows also still has this bug today.


With the certificate_authorities field in the current CertificateRequest
handshake message, these are only (fixable) bugs.  With the removal
of the CertificateRequest handshake message, this problem would be
promoted to a TLSv1.3 protocol design flaw, and become unfixable.


-Martin


From nobody Wed Oct 22 09:00:01 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DBA1ACDB7 for ; Wed, 22 Oct 2014 08:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXWZT43OzKTL for ; Wed, 22 Oct 2014 08:59:51 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 593B91ACDB2 for ; Wed, 22 Oct 2014 08:59:51 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 78A2B475B1; Wed, 22 Oct 2014 15:59:50 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 6A3AD475A8; Wed, 22 Oct 2014 15:59:50 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 65875202A; Wed, 22 Oct 2014 15:59:50 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 22 Oct 2014 11:59:49 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 22 Oct 2014 11:59:49 -0400
From: "Salz, Rich" 
To: Martin Thomson , Ilari Liusvaara 
Date: Wed, 22 Oct 2014 11:59:48 -0400
Thread-Topic: [TLS] Summary of discussion regarding spontaneuous authentication
Thread-Index: Ac/uBJpun18SUwMPSzKfsfH4En909AADHBOA
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4F98@USMBX1.msg.corp.akamai.com>
References:   <20141022125359.GA18704@LK-Perkele-VII>  <20141022132623.GA19894@LK-Perkele-VII> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bSkdsxdQwz8dFSUxZW14ToixdrU
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 15:59:53 -0000

> I tend to think that we need a more general mechanism for indicating
> support for certificate types and signature algorithms.  Maybe we could
> unconditionally include those in the early handshake instead.

Yes.  In two years when MSFT and Google start deprecating SHA-2 for Keccak,=
 it'd be nice to know which cert chain to send.  Or when I don't know wheth=
er to send an RSA or ECDSA certificate next year.=20

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Wed Oct 22 09:03:25 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5AC1ACDB2 for ; Wed, 22 Oct 2014 09:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei3T7VL7VALr for ; Wed, 22 Oct 2014 09:03:19 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3724B1ACD82 for ; Wed, 22 Oct 2014 09:03:19 -0700 (PDT)
Received: by mail-qa0-f51.google.com with SMTP id k15so2595304qaq.24 for ; Wed, 22 Oct 2014 09:03:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=zfboSt/zZdkhJIrv6NHOk8O2YN7CYjK7rw/IlxhKim8=; b=XSixlA4qrJNSLGduXVnQ5K9Rc1NUufrDmvpVu0RKSL4mQbcpCnQ3i205gYqq+I3MUb KIqpI+kisKO4xwFzHZr8mHWvU2E9muLbxxeEjwYyUeym+lvuOVReo4komZv6FADrIkDg wOlIqsd38zKdo7odX74noj8NmlNdCu786ZgQBGZNEdvo6qO9zx/orq5SqjWlkY5ZaOOI BD6lQ63ujXTgYRGzP/WbQdQnBMGWRGEn4GkTM5OZT+Dz7igIG1Drz9wndm35jR1oQUGv Xvm71Q7aAFvOCLzjuya8BBQ3CyfUU0LltUmyDaWI91tEZxRvyHxdaP7JERlzpkcdyDSt 42Hg==
X-Gm-Message-State: ALoCoQnuXZcvXHDqFINmDyRWmuwBahJQSdkEQI/FuH5cGRQVdC9ntk1gy3iXa+TptcYZPkKCO3BS
X-Received: by 10.224.11.6 with SMTP id r6mr4986564qar.42.1413993798043; Wed, 22 Oct 2014 09:03:18 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:e7:4db0:7b95:1f7b:4e12? ([2601:a:2a00:e7:4db0:7b95:1f7b:4e12]) by mx.google.com with ESMTPSA id i2sm13922116qay.32.2014.10.22.09.03.17 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Oct 2014 09:03:17 -0700 (PDT)
Message-ID: <5447D561.1010503@nthpermutation.com>
Date: Wed, 22 Oct 2014 12:03:45 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040501070705060400050904"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XB1b1Uc5ZSuSeytQXWTtXMlDesU
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 16:03:24 -0000

This is a multi-part message in MIME format.
--------------040501070705060400050904
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 10/21/2014 10:52 AM, Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/issues/80
>
> Today we discussed the possibility of requiring support for compressed 
> points
> in TLS 1.3 now that the IPR has expired.
>
> Specifically, I propose that for TLS 1.3, we:
>
> - Use only compressed points for the existing curves (and presumably
>   whatever superior format is defined for the CFRG-recommended
>   curves, as appropriate).
>
> - Deprecate the Supported Point Formats extension for TLS 1.3

After thinking about this longer - how actually would this work 
negotiation wise?  Specifically "us[ing] only compressed points"?

AFAICT, all you're going to do is make the negotiation even more 
complex.  The TLS1.3 clients and servers will still need to implement 
uncompressed points to talk to TLS1.2 and before clients and servers.  A 
TLS1.3 server will still need to understand an offered Supported Point 
Format extension from a TLS1.2 client to figure out if it can send a 
compressed point public key.  (I think) A TLS1.3 client will still need 
to offer the Supported Point Format extension in case it's talking to a 
1.2 server if the client wants to offer a compressed public key.

Is there any benefit you get besides  the savings of 1/2 of a public key 
on the wire from the server to the client?  Call it 32 octets for a 256 
bit X9.63 key.

The only way you get away from this is if you have prior knowledge of 
the server implementation or you put TLS1.3 on a new port (which to be 
clear I'm not suggesting).

And you still need support for the uncompressed form for certificates 
for quite a very long time (RFC5480).

So what's the argument for doing this besides "we can"?

Mike


>
>
> For RFC 4492-bis, we might also consider requiring support for compressed
> points as well as uncompressed (already required) but this seems like a
> separable issue, since it's mostly in service of optimization rather than
> simplicity.
>
> What do people think?
> -Ekr
>
>
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--------------040501070705060400050904
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/21/2014 10:52 AM, Eric Rescorla
      wrote:

    

    

      
https://github.com/tlswg/tls13-spec/issues/80
        


        

        
Today we discussed the possibility of requiring support for
          compressed points

        
in TLS 1.3 now that the IPR has expired.

        


        

        
Specifically, I propose that for TLS 1.3, we:

        


        

        
- Use only compressed points for the existing curves (and
          presumably

        
  whatever superior format is defined for the
          CFRG-recommended

        
  curves, as appropriate).

        


        

        
- Deprecate the Supported Point Formats extension for TLS
          1.3

      

    

    

    After thinking about this longer - how actually would this work
    negotiation wise?  Specifically "us[ing] only compressed points"?

    

    AFAICT, all you're going to do is make the negotiation even more
    complex.  The TLS1.3 clients and servers will still need to
    implement uncompressed points to talk to TLS1.2 and before clients
    and servers.  A TLS1.3 server will still need to understand an
    offered Supported Point Format extension from a TLS1.2 client to
    figure out if it can send a compressed point public key.  (I think)
    A TLS1.3 client will still need to offer the Supported Point Format
    extension in case it's talking to a 1.2 server if the client wants
    to offer a compressed public key.  

    

    Is there any benefit you get besides  the savings of 1/2 of a public
    key on the wire from the server to the client?  Call it 32 octets
    for a 256 bit X9.63 key.   

    

    The only way you get away from this is if you have prior knowledge
    of the server implementation or you put TLS1.3 on a new port (which
    to be clear I'm not suggesting).

    

    And you still need support for the uncompressed form for
    certificates for quite a very long time (RFC5480).   

    

    So what's the argument for doing this besides "we can"?

    

    Mike

    

    

    

      

        


        

        


        

        
For RFC 4492-bis, we might also consider requiring support
          for compressed

        
points as well as uncompressed (already required) but this
          seems like a

        
separable issue, since it's mostly in service of
          optimization rather than

        
simplicity.

        


        

        
What do people think?

        
-Ekr

        


        

        


        

        


        

        


        

        


        

      

      

      

      

      
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


    

    

  


--------------040501070705060400050904--


From nobody Wed Oct 22 09:11:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4861AC417 for ; Wed, 22 Oct 2014 09:11:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leSNu1T2dFgw for ; Wed, 22 Oct 2014 09:11:15 -0700 (PDT)
Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 365261ACD6B for ; Wed, 22 Oct 2014 09:11:14 -0700 (PDT)
Received: by mail-yh0-f42.google.com with SMTP id t59so3736241yho.15 for ; Wed, 22 Oct 2014 09:11:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vtGfj0L+S7RSLZOFokJmfq/3SSJ0ESSk+8Z4QAzc+4U=; b=yokxlm4FSxYgmDKDAkviwIwMGqXy5uLTSFsXtdiBPjDDlWRl8CJofKK6GQRElBZoyD cltmmRnMqgHi83XujACW1A+clXvOh550Q78ji5x1/IDfl4uDQXsywOPeHYpUQ7fem4rR 9/9HZYU3mcwzzXJKEeJwz+090IhC11KKrYdnjxmtGDyFsWNt2DUJeMSPnS5osKAT00X1 05Df72SFWKO4y9L3iBX1FDDtls1MXbrJZjTevnzI0dlT7EKYTPIJY7usitQjzhGjDTO4 hIdyV7uxBIjkr5YAjvtNfiFzMK/40ox+hB2POi6nukJnzn/lf7Qu+Zha2RiNtX4hNpXq MFgQ==
MIME-Version: 1.0
X-Received: by 10.236.22.37 with SMTP id s25mr5181700yhs.138.1413994270742; Wed, 22 Oct 2014 09:11:10 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Wed, 22 Oct 2014 09:11:10 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Wed, 22 Oct 2014 09:11:10 -0700 (PDT)
In-Reply-To: <544677AE.4000005@nthpermutation.com>
References:  <544677AE.4000005@nthpermutation.com>
Date: Wed, 22 Oct 2014 09:11:10 -0700
Message-ID: 
From: Watson Ladd 
To: Michael StJohns 
Content-Type: multipart/alternative; boundary=e89a8f642b4638e1a905060532e2
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/92PZcsSywvrnJzkZ5Xe31Mkrcdg
Cc: tls@ietf.org
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 16:11:21 -0000

--e89a8f642b4638e1a905060532e2
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 21, 2014 at 8:11 AM, Michael StJohns 
wrote:
> On 10/21/2014 10:52 AM, Eric Rescorla wrote:
>
> https://github.com/tlswg/tls13-spec/issues/80
>
> Today we discussed the possibility of requiring support for compressed
> points
> in TLS 1.3 now that the IPR has expired.
>
> Specifically, I propose that for TLS 1.3, we:
>
> - Use only compressed points for the existing curves (and presumably
> whatever superior format is defined for the CFRG-recommended
> curves, as appropriate).
>
> - Deprecate the Supported Point Formats extension for TLS 1.3
>
>
> I'm pretty much opposed to the former and I guess by extension the latter.
>
> There's a very large body of code that doesn't support anything except
type
> 0x04(uncompressed) X9.63 point encodings. If you want to add support for
> compressed points (or hybrid compressed), I don't think that's
necessarily a
> bad idea, but not at the expense of removing support for uncompressed
> points. If you wanted to remove the supported point format extension, I
> guess you could mandate support for both compressed and uncompressed (and
> hybrid?).

There is a large body of code that doesn't support TLS 1.3 as well.
>
> As a second item, I would estimate the chance we're going to see
compressed
> points in X509 certificates as a regular thing prior to about 10 years
from
> now as very small, meaning that any general transition to EC based suites
is
> going to require uncompressed point support.

Yes, but uncompressed points are not a security concern in X509, but they
are in ECDH. Furthermore, the cost of adding compression support is very
small: it's a square root, a check, and potentially flipping the sign. The
benefit is that invalid point attacks are much harder to carry out.

>
> Lastly, while the base IPR for point compression seems to be no longer of
> concern, I've still been told to avoid it for a few more years due to
> implementation patents related to compression. I'm not sure how worrisome
> that is, but its one of the reasons that binary curves aren't in broader
use
> still.
>
> Just my $.02
>
> Mike
>
>
>
> For RFC 4492-bis, we might also consider requiring support for compressed
> points as well as uncompressed (already required) but this seems like a
> separable issue, since it's mostly in service of optimization rather than
> simplicity.
>
> What do people think?
> -Ekr
>
>
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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

--e89a8f642b4638e1a905060532e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Oct 21, 2014 at 8:11 AM, Michael StJohns <msj@nthpermutation.com> wrote:
> On 10/21/2014 10:52 AM, Eric Rescorla wrote:

>

> https://gith=
ub.com/tlswg/tls13-spec/issues/80

>

> Today we discussed the possibility of requiring support for compressed=


> points

> in TLS 1.3 now that the IPR has expired.

>

> Specifically, I propose that for TLS 1.3, we:

>

> - Use only compressed points for the existing curves (and presumably
> whatever superior format is defined for the CFRG-recommended

> curves, as appropriate).

>

> - Deprecate the Supported Point Formats extension for TLS 1.3

>

>

> I'm pretty much opposed to the former and I guess by extension the=
 latter.

>

> There's a very large body of code that doesn't support anythin=
g except type

> 0x04(uncompressed) X9.63 point encodings. If you want to add support f=
or

> compressed points (or hybrid compressed), I don't think that's=
 necessarily a

> bad idea, but not at the expense of removing support for uncompressed<=
br>
> points. If you wanted to remove the supported point format extension, =
I

> guess you could mandate support for both compressed and uncompressed (=
and

> hybrid?).


There is a large body of code that doesn't support TLS 1=
.3 as well.

>

> As a second item, I would estimate the chance we're going to see c=
ompressed

> points in X509 certificates as a regular thing prior to about 10 years=
 from

> now as very small, meaning that any general transition to EC based sui=
tes is

> going to require uncompressed point support.


Yes, but uncompressed points are not a security concern in X=
509, but they are in ECDH. Furthermore, the cost of adding compression supp=
ort is very small: it's a square root, a check, and potentially flippin=
g the sign. The benefit is that invalid point attacks are much harder to ca=
rry out.


>

> Lastly, while the base IPR for point compression seems to be no longer=
 of

> concern, I've still been told to avoid it for a few more years due=
 to

> implementation patents related to compression. I'm not sure how wo=
rrisome

> that is, but its one of the reasons that binary curves aren't in b=
roader use

> still.

>

> Just my $.02

>

> Mike

>

>

>

> For RFC 4492-bis, we might also consider requiring support for compres=
sed

> points as well as uncompressed (already required) but this seems like =
a

> separable issue, since it's mostly in service of optimization rath=
er than

> simplicity.

>

> What do people think?

> -Ekr

>

>

>

>

>

>

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf=
.org/mailman/listinfo/tls

>

>

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf=
.org/mailman/listinfo/tls

>



--

"Those who would give up Essential Liberty to purchase a little Tempor=
ary Safety deserve neither Liberty nor Safety."

-- Benjamin Franklin


--e89a8f642b4638e1a905060532e2--


From nobody Wed Oct 22 09:34:37 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6602D1ACDDE for ; Wed, 22 Oct 2014 09:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl5kJ1sKiiW6 for ; Wed, 22 Oct 2014 09:34:34 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51ACE1ACDDC for ; Wed, 22 Oct 2014 09:34:34 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id fb4so1891210wid.10 for ; Wed, 22 Oct 2014 09:34:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mkpQNZcfGgE4QLJahyrYdMmpY/OQhbLHrSZYcSAqF+Y=; b=hrgnqFU7fC+L5IQ5Mr96WtJVAdDwAZlj+0L4b3Dtz9kXaKYeP3oaXPEtHFOAEAkRsk rh7mAd2EhLgeU/vQ3/b0DLCDTbVuqa9v6hGDcvzsVxPdrOCXp6C3Cp1Zg2pL3DLonNNg rcEPQHxVPLBR80UIbmEhYVh+vLaf3zUVm/nms=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mkpQNZcfGgE4QLJahyrYdMmpY/OQhbLHrSZYcSAqF+Y=; b=ir13NzwJ9Dpa5IHgTMAkZmGHK1aaWi14Ujl1fei+hDnfRSODRKYPw4qJDcK4g8syLI ZTTrRecv+TJU52tr6nXCF7ET+dI+rPFLdhviTgbjipl3jfThOu6Fm3QuzEB+b2M3rlYM skCKSGIQPvFGWtTDY4lAlar4gXYEp1paibs3WFwPO8uoEQdsy3CxYc+yFcQjbIz7ObVD UQmJ/bgUb/aBjEpusu74j/5WMt0O3r1v/hQsVDQJXUK6uiwMbtNzfr2LNMfCzyLT+zx4 CvaujlPooIuL9kVsBdIfGcOs1lwYtCw/2+NKWK1p+HrhWlUrcNH6tbzBfhYjUdkGeFDr fUQg==
X-Gm-Message-State: ALoCoQm8LaezoYFvZN98g+1gdHkmu0uoY7w4dE8Uy0pOLkAN+Dfjl/gcHDbk9M2Xl1sbU5AZkmQv
X-Received: by 10.180.74.173 with SMTP id u13mr38909204wiv.64.1413995672938; Wed, 22 Oct 2014 09:34:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.2.65 with HTTP; Wed, 22 Oct 2014 09:34:12 -0700 (PDT)
In-Reply-To: <20141022151819.44A791AF05@ld9781.wdf.sap.corp>
References:  <20141022151819.44A791AF05@ld9781.wdf.sap.corp>
From: Tom Ritter 
Date: Wed, 22 Oct 2014 12:34:12 -0400
Message-ID: 
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QkQ61H-6z_8Mx4yzjLlSOL5bQm4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 16:34:35 -0000

On 22 October 2014 11:18, Martin Rex  wrote:
]> Apple Safari seems to be notoriously broken when it comes to SSL client
> certificate selection, because it fails to process the certificate_authorities
> field from a CertificateRequest handshake message and remove obviously
> unacceptable certs from the list of credentials that the user is
> presented to select from.

Hah, I did not know that, but can confirm this is the case on an
up-to-date Safari+OSX10.9.

-tom


From nobody Wed Oct 22 09:45:04 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B701ACDDA for ; Wed, 22 Oct 2014 09:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-gBwk8A9Sty for ; Wed, 22 Oct 2014 09:45:00 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93C11ACD86 for ; Wed, 22 Oct 2014 09:44:59 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id n3so1316431wiv.5 for ; Wed, 22 Oct 2014 09:44:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:content-type; bh=epYwAMbKTLGQMRmrzOQ3rrkNHapitJKrgW7DQtpPWfk=; b=b+RT+eYDKj8xRG+X1MtVHoAkNRuecr33bnvjIvQJLhokGe0iIDaLZTzoVfc8HnCnuo U6f7FbQqgsY7WB+D+kQeiDQmvFqoRGreb+/W4lUPnoRZea8jNtaHTBkArvYgqxgxJHxD H6yXpv0SW0quComYT0i5cw/Cn0G7xGmcBkuFVgIyz4P30t1dUR8oD+Dp0LtgqH0IZckH D4wadqa5FIS5WrkRVqG1JYfJPxJLCDjDiY3gJxAYR1eVAJqUhu8PwaUiU+GzC+t1YD2S eI3FtHUWmJRo+4/ODwVr782IZsko4JN53fwc72E/UakTGsGXmHh3emav+CyAXENJWySl dr8g==
X-Received: by 10.180.24.167 with SMTP id v7mr8913621wif.41.1413996298552; Wed, 22 Oct 2014 09:44:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.242.39 with HTTP; Wed, 22 Oct 2014 09:44:18 -0700 (PDT)
From: Ryan Carboni 
Date: Wed, 22 Oct 2014 09:44:18 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=f46d0442878616cafc050605abb4
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hY-j_orsPUxAEU3STZUVLyoAlOM
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 16:45:03 -0000

--f46d0442878616cafc050605abb4
Content-Type: text/plain; charset=UTF-8

From: "Richard Fussenegger, BSc"

> [*] Better would be 'from all ciphers in use' otherwise one ends up with
> a (insert ridiculous high value here) bit key while only using 128 bit
> ciphers in the configuration. Dropping the key if a new stronger
> configuration is loaded seems like a good idea to me at this point. I'm
> looking at this from a performance perspective and glimpsing over to the
> fact that the cryptography community agrees that 128 bit security will
> be enough for the next 10 to 20 years.[2] I really can't tell if this
> would be problematic from an implementation point of view. I think that
> single hosts won't have a problem here and I guess that it wouldn't be
> for clusters as well. The cluster configuration should be in sync but it
> could become a problem if one node has a differing configuration (for
> whatever reason). What opinion/insights do you have on this?


 Quantum computers are reaching 512-qubits now.
http://www.bbc.com/news/science-environment-27632140

Quantum cryptography would result in key-sizes effectively being halved,
and in 15 to 40 years a quantum computer could potentially be built by a
nationstate to enhance known cryptographic attacks and reduce keyspaces
substantially.

It's unlikely though that the NSA will devote quantum computing to breaking
the encryption of cat videos.

I suggest an advisory that for unauthenticated encryption, 128-bits are
used, and for authenticated encryption 256-bits or more are used. The only
issue is that browsers tell you the whole page is encrypted the same way
even though elements of the page use different sorts of encryption than the
body of the page.

--f46d0442878616cafc050605abb4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



From: "Richard Fussenegger, BSc" 

[*] Better would be 'from all ciphers in use' otherwise one ends up=
 with

a (insert ridiculous high value here) bit key while only using 128 bit

ciphers in the configuration. Dropping the key if a new stronger

configuration is loaded seems like a good idea to me at this point. I'm=


looking at this from a performance perspective and glimpsing over to the
fact that the cryptography community agrees that 128 bit security will

be enough for the next 10 to 20 years.[2] I really can't tell if this
would be problematic from an implementation point of view. I think that

single hosts won't have a problem here and I guess that it wouldn't=
 be

for clusters as well. The cluster configuration should be in sync but it
could become a problem if one node has a differing configuration (for

whatever reason). What opinion/insights do you have on this?

=C2=A0Quantum computers are reaching 512-qubits now. http://www.bbc=
.com/news/science-environment-27632140 

Quantum crypt=
ography would result in key-sizes effectively being halved, and in 15 to 40=
 years a quantum computer could potentially be built by a nationstate to en=
hance known cryptographic attacks and reduce keyspaces substantially.
It's unlikely though that the NSA will devote quantum comp=
uting to breaking the encryption of cat videos.

I suggest an advisory that for unauthenticated encryption, 128-bits are u=
sed, and for authenticated encryption 256-bits or more are used. The only i=
ssue is that browsers tell you the whole page is encrypted the same way eve=
n though elements of the page use different sorts of encryption than the bo=
dy of the page. 


--f46d0442878616cafc050605abb4--


From nobody Wed Oct 22 09:51:55 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7201ACDAA for ; Wed, 22 Oct 2014 09:51:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7TmLGmJ1tPl for ; Wed, 22 Oct 2014 09:51:52 -0700 (PDT)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D316D1ACE23 for ; Wed, 22 Oct 2014 09:51:51 -0700 (PDT)
Received: by mail-qc0-f182.google.com with SMTP id i17so3035420qcy.27 for ; Wed, 22 Oct 2014 09:51:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pTZ5tIECa6hkxpbs2N907cUZJj8gN6jhzds1mjrDvw4=; b=C6y5IyZCyjS+Ray2NPGd/L3AGcbhi67DImgXL1jeav7uLfez6RBvBccj2u/bFo4pLU ItOTWiShGlwxdLIfEcd6kfQyNLnXEFHKvTNwd71ZZI4wPJrEfScwrzq9KNFD/2EkDr/3 RlKkMqCaTlbcrCZehwHn5nMPqxiIMzt1REhSLrUTaA8PUfTfVUoUvzVifUhJNC42wN1s XjpZcQxWMdhkzyfT99j0aNTy4BCg/QD1u8AoBOEgwH90eCG4cf1UFj+IiN3KxoAQpPZ+ opFlZ+ANlrBvuPeSNCGYmDTTiAb+p68OKOcQ4C2JYpQgJ+3ulh4rdOLU4epLrb8yRq+S WTow==
X-Gm-Message-State: ALoCoQkhZw24GpoANbtrSgnf7M2biCL3tN/uFV/TJzjyXTP+/aewRaLyjZEgfJtJimlrt2CpgWPH
MIME-Version: 1.0
X-Received: by 10.140.17.67 with SMTP id 61mr54146650qgc.59.1413996706446; Wed, 22 Oct 2014 09:51:46 -0700 (PDT)
Received: by 10.96.166.35 with HTTP; Wed, 22 Oct 2014 09:51:46 -0700 (PDT)
X-Originating-IP: [2601:8:b300:a5:e403:155c:52c9:7844]
In-Reply-To: <20141022151819.44A791AF05@ld9781.wdf.sap.corp>
References:  <20141022151819.44A791AF05@ld9781.wdf.sap.corp>
Date: Wed, 22 Oct 2014 09:51:46 -0700
Message-ID: 
From: Joseph Salowey 
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=001a11c0fa2866d68f050605c368
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/b0pN3ZNWWaQM1lhs3cY4GpjNNPU
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 16:51:54 -0000

--001a11c0fa2866d68f050605c368
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 22, 2014 at 8:18 AM, Martin Rex  wrote:

> Martin Thomson wrote:
> >
> > We discussed the removal of the CertificateRequest and we will permit
> > the client to unilaterally send authentication.
> >
> > The theory here is that clients tend to know whether they need to
> > authenticate.
>
> This looks like a bad idea to me.
> The by far most important information in the current CertificateRequest
> handshake message is the "certification_authorities" field, which indicates
> certificate issuers which the server considers acceptable.
> In SSLv3 and TLSv1.0 the certificate_authorities field was required
> to be non-empty and no (server) behaviour was defined for the meaning
> of an empty certification_authorities field in CertificateRequest.
>
> The TLSv1.1 and TLSv1.2 specification contain a defect in that they
> modified the PDU definition to allow an empty certification_authorities
> field in CertificateRequest, but failed to define (require) a server
> behaviour when the server does not send this information.
> Without the requirement, that the serer MUST NOT abort the TLS handshake
> when sending an empty certificate_authorities and receiving a certificate
> which it does not trust, the use of an empty certificate_authorities
> field does not make sense.
>
>
> With recent versions of Lync, Microsoft seems to automatically create a
> Lync-specific "SSL client identity" that works for nothing but Lync, but
> will successfully interfere with SSL client credentials selections when
> browsers are using an SSL client identity for accessing regular Web sites.
>
> To make SSL client certificate authentication work reasonably
> a CertificateRequest that conveys acceptable certificate_authorities
> for the specific handshake is absolutely necessary.
>
> Apple Safari seems to be notoriously broken when it comes to SSL client
> certificate selection, because it fails to process the
> certificate_authorities
> field from a CertificateRequest handshake message and remove obviously
> unacceptable certs from the list of credentials that the user is
> presented to select from.   I've had customers report connection
> failures to our AppServers, and from the server-side error messages
> I could see that the client was trying to connect with some appleid
> certificate that our server didn't trust (and certainly never announced
> in the CertificateRequest.certificate_authorities field.
>
> Microsoft had a similar problem in WinHTTP in 2005
> http://support.microsoft.com/kb/909425/en
>
> After WinHTTP was fixed to provide the necessary information
> to application callers, it is still necessary for application callers
> to actually _use_ that information to select only acceptable certificates,
> and that seems to take years to happen.
> This is the fix for Office/WebDAV:
> http://support.microsoft.com/kb/2647954/en
>
> And Apple Safari 4 Windows also still has this bug today.
>
>
> With the certificate_authorities field in the current CertificateRequest
> handshake message, these are only (fixable) bugs.  With the removal
> of the CertificateRequest handshake message, this problem would be
> promoted to a TLSv1.3 protocol design flaw, and become unfixable.
>
>
[Joe]  I'm also concerned that removing the certificate request in favor of
some application indication will leave behind applications that do not
currently have a mechanism to communicate this.   If we are going to remove
the certificate request I think we will need to communicate this
information in the handshake itself or perhaps have a "reconnection
request".




>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a11c0fa2866d68f050605c368
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Wed, Oct 22, 2014 at 8:18 AM, Martin Rex <mrex@sap.com> wrot=
e:
Martin Thomson wrote:

>

> We discussed the removal of the CertificateRequest and we will permit<=
br>
> the client to unilaterally send authentication.

>

> The theory here is that clients tend to know whether they need to

> authenticate.



This looks like a bad idea to me.

The by far most important information in the current CertificateRequest

handshake message is the "certification_authorities" field, which=
 indicates

certificate issuers which the server considers acceptable.

In SSLv3 and TLSv1.0 the certificate_authorities field was required

to be non-empty and no (server) behaviour was defined for the meaning

of an empty certification_authorities field in CertificateRequest.



The TLSv1.1 and TLSv1.2 specification contain a defect in that they

modified the PDU definition to allow an empty certification_authorities

field in CertificateRequest, but failed to define (require) a server

behaviour when the server does not send this information.

Without the requirement, that the serer MUST NOT abort the TLS handshake
when sending an empty certificate_authorities and receiving a certificate
which it does not trust, the use of an empty certificate_authorities

field does not make sense.





With recent versions of Lync, Microsoft seems to automatically create a

Lync-specific "SSL client identity" that works for nothing but Ly=
nc, but

will successfully interfere with SSL client credentials selections when

browsers are using an SSL client identity for accessing regular Web sites.<=
br>


To make SSL client certificate authentication work reasonably

a CertificateRequest that conveys acceptable certificate_authorities

for the specific handshake is absolutely necessary.



Apple Safari seems to be notoriously broken when it comes to SSL client

certificate selection, because it fails to process the certificate_authorit=
ies

field from a CertificateRequest handshake message and remove obviously

unacceptable certs from the list of credentials that the user is

presented to select from.=C2=A0 =C2=A0I've had customers report connect=
ion

failures to our AppServers, and from the server-side error messages

I could see that the client was trying to connect with some appleid

certificate that our server didn't trust (and certainly never announced=


in the CertificateRequest.certificate_authorities field.



Microsoft had a similar problem in WinHTTP in 2005

htt=
p://support.microsoft.com/kb/909425/en



After WinHTTP was fixed to provide the necessary information

to application callers, it is still necessary for application callers

to actually _use_ that information to select only acceptable certificates,<=
br>
and that seems to take years to happen.

This is the fix for Office/WebDAV:

ht=
tp://support.microsoft.com/kb/2647954/en



And Apple Safari 4 Windows also still has this bug today.





With the certificate_authorities field in the current CertificateRequest
handshake message, these are only (fixable) bugs.=C2=A0 With the removal
of the CertificateRequest handshake message, this problem would be

promoted to a TLSv1.3 protocol design flaw, and become unfixable.



[Joe] =C2=A0I'm also concerned that removing the certi=
ficate request in favor of some application indication will leave behind ap=
plications that do not currently have a mechanism to communicate this. =C2=
=A0 If we are going to remove the certificate request I think we will need =
to communicate this information in the handshake itself or perhaps have a &=
quot;reconnection request". =C2=A0


=C2=A0



-Martin




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--001a11c0fa2866d68f050605c368--


From nobody Wed Oct 22 10:02:26 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6FD1ACE5D for ; Wed, 22 Oct 2014 10:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQFwI_FrBTpv for ; Wed, 22 Oct 2014 10:02:17 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64DD71ACE59 for ; Wed, 22 Oct 2014 10:02:16 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id rp18so3940345iec.13 for ; Wed, 22 Oct 2014 10:02:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=fx5njPoPavQ3dNpCwfMVAGgIXvBDlyGE69mAPWUSWX4=; b=gQYyVWaqAW+mJx8kgL99IkbElnxQFkxFohpmQmwYotmDC8V/3fOr7Y2NIkRn2RMMPb vDZ8oiKqvf0n4BMEKp5P1V/1YGFqswE9I4t9sqPZbO49ltktZalegrWOJYvphY3x2SRw ibkChv94l12/2RdVTVKdIlU0J2r+lDKpKLlSqzi/8UCM69uN8NcO7UgE/US4zTqVSLiN osUwOJDO38u5tAM+xMEu+icc2BRdbrybFZdWVC032drJ6Eb1iDOe5mZuEYtx0sgF9/92 Y3M/b5lfjyG+7hw1FKX+KJWA/G1dhEft94FHi+i7nJ1v7In3k7E7by4JkZHCLlTO1VKK tjsg==
X-Received: by 10.42.151.66 with SMTP id d2mr3067349icw.74.1413997335830; Wed, 22 Oct 2014 10:02:15 -0700 (PDT)
Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id o3sm968872igv.19.2014.10.22.10.02.15 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Oct 2014 10:02:15 -0700 (PDT)
Message-ID: <5447E307.3010104@gmail.com>
Date: Wed, 22 Oct 2014 13:01:59 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Watson Ladd 
References:  <544677AE.4000005@nthpermutation.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020505050207050404070500"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LzgQ1iP6hf-fov4i4Zk1GWsyvGY
Cc: tls@ietf.org
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 17:02:21 -0000

This is a multi-part message in MIME format.
--------------020505050207050404070500
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi Watson:

I do not understand your statement below: the cost of "decompressing" 
points may be not that insignificant and, depending on application, one 
might rather send uncompressed points instead.

For simplicity, let us assume a short-Weierstrass curve E with defining 
equation y^2 = x^3 + a x + b (mod p). (A similar argument holds for 
other curves, of course.)

If one receives an uncompressed alleged point R:=(x,y), one has to check 
whether this is indeed on the curve E. This comes roughly at cost 2S+1M 
(where S=squaring; M=multiply).
If one receives a compressed point R':=(x,y') and requires the 
corresponding uncompressed point R, one has to compute a solution y to 
the equation y^2=alpha, where alpha:=x^3+ax+b (mod p) and (if there is a 
solution) pick y or p-y, depending on the binary value y'. This comes at 
roughly cost 1S + 1M+1SQRT (where SQRT=square root).

The trade-off here is that point compression slightly saves on 
communication bandwidth, whereas it does increase computational cost of 
scalar multiplies.
{Rough ballpark for 256-bit curve: 64 octet uncompressed point vs. 32 
octet compressed point; curve check uncompressed point roughly <0.2% 
cost scalar multiply vs. ~10% cost scalar multiply (based on figures I 
have seen floating around on the cfrg mailing list).}

Your suggested "security concern" seems to be that implementers will 
somehow not perform the curve check (why?) and that, by using point 
compression, you simply enforce it indirectly (since recomputing the 
uncompressed point from the compressed one includes checking whether the 
x-value is indeed the x-coordinate of a possible curve point). For 
implementers that *do* perform the curve check and do care more about 
performance than about the 32-octet communication savings, this would 
present a disadvantage.

The only case where the latter does not incur such a large performance 
hit seems to be in cases where scalar multiplication does not use the 
y-coordinate at all (since then one does not care about y' and simply 
sees whether alpha is a quadratic residue). This does however restrict 
implementation freedom.

If one were to be concerned about implementation attacks, why not have 
people compute a compressed point R':=(x,y') from a received 
uncompressed point R:=(x,y) {this simply requires taking y':=y (mod 2), 
i.e., determining the parity of y} and then do as you suggested.

Using uncompressed points gives people two mechanisms for preventing 
invalid point attacks (via curve check or point decompression), at 
slightly higher communication cost (32 octets) that seems easy to accept 
in most TLS applications. Allowing freedom to choose either format gives 
people choice, also on communication cost side, at trivial cost of 
having a single octet indicator.

This leads us back to the representation formats we currently have.

Best regards, Rene

==
Yes, but uncompressed points are not a security concern in X509, but 
they are in ECDH. Furthermore, the cost of adding compression support is 
very small: it's a square root, a check, and potentially flipping the 
sign. The benefit is that invalid point attacks are much harder to carry 
out.

On 10/22/2014 12:11 PM, Watson Ladd wrote:
>
> On Tue, Oct 21, 2014 at 8:11 AM, Michael StJohns 
> > wrote:
> > On 10/21/2014 10:52 AM, Eric Rescorla wrote:
> >
> > https://github.com/tlswg/tls13-spec/issues/80
> >
> > Today we discussed the possibility of requiring support for compressed
> > points
> > in TLS 1.3 now that the IPR has expired.
> >
> > Specifically, I propose that for TLS 1.3, we:
> >
> > - Use only compressed points for the existing curves (and presumably
> > whatever superior format is defined for the CFRG-recommended
> > curves, as appropriate).
> >
> > - Deprecate the Supported Point Formats extension for TLS 1.3
> >
> >
> > I'm pretty much opposed to the former and I guess by extension the 
> latter.
> >
> > There's a very large body of code that doesn't support anything 
> except type
> > 0x04(uncompressed) X9.63 point encodings. If you want to add support for
> > compressed points (or hybrid compressed), I don't think that's 
> necessarily a
> > bad idea, but not at the expense of removing support for uncompressed
> > points. If you wanted to remove the supported point format extension, I
> > guess you could mandate support for both compressed and uncompressed 
> (and
> > hybrid?).
>
> There is a large body of code that doesn't support TLS 1.3 as well.
> >
> > As a second item, I would estimate the chance we're going to see 
> compressed
> > points in X509 certificates as a regular thing prior to about 10 
> years from
> > now as very small, meaning that any general transition to EC based 
> suites is
> > going to require uncompressed point support.
>
> Yes, but uncompressed points are not a security concern in X509, but 
> they are in ECDH. Furthermore, the cost of adding compression support 
> is very small: it's a square root, a check, and potentially flipping 
> the sign. The benefit is that invalid point attacks are much harder to 
> carry out.
>
> >
> > Lastly, while the base IPR for point compression seems to be no 
> longer of
> > concern, I've still been told to avoid it for a few more years due to
> > implementation patents related to compression. I'm not sure how 
> worrisome
> > that is, but its one of the reasons that binary curves aren't in 
> broader use
> > still.
> >
> > Just my $.02
> >
> > Mike
> >
> >
> >
> > For RFC 4492-bis, we might also consider requiring support for 
> compressed
> > points as well as uncompressed (already required) but this seems like a
> > separable issue, since it's mostly in service of optimization rather 
> than
> > simplicity.
> >
> > What do people think?
> > -Ekr
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org 
> > https://www.ietf.org/mailman/listinfo/tls
> >
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org 
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
> --
> "Those who would give up Essential Liberty to purchase a little 
> Temporary Safety deserve neither Liberty nor Safety."
> -- Benjamin Franklin
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


--------------020505050207050404070500
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Watson:

      

      I do not understand your statement below: the cost of
      "decompressing" points may be not that insignificant and,
      depending on application, one might rather send uncompressed
      points instead.

      

      For simplicity, let us assume a short-Weierstrass curve E with
      defining equation y^2 = x^3 + a x + b (mod p). (A similar argument
      holds for other curves, of course.)

      

      If one receives an uncompressed alleged point R:=(x,y), one has to
      check whether this is indeed on the curve E. This comes roughly at
      cost 2S+1M (where S=squaring; M=multiply).

      If one receives a compressed point R':=(x,y') and requires the
      corresponding uncompressed point R, one has to compute a solution
      y to the equation y^2=alpha, where alpha:=x^3+ax+b (mod p) and (if
      there is a solution) pick y or p-y, depending on the binary value
      y'. This comes at roughly cost 1S + 1M+1SQRT (where SQRT=square
      root).

      

      The trade-off here is that point compression slightly saves on
      communication bandwidth, whereas it does increase computational
      cost of scalar multiplies.

      {Rough ballpark for 256-bit curve: 64 octet uncompressed point vs.
      32 octet compressed point; curve check uncompressed point roughly
      <0.2% cost scalar multiply vs. ~10% cost scalar multiply (based
      on figures I have seen floating around on the cfrg mailing list).}

      

      Your suggested "security concern" seems to be that implementers
      will somehow not perform the curve check (why?) and that, by using
      point compression, you simply enforce it indirectly (since
      recomputing the uncompressed point from the compressed one
      includes checking whether the x-value is indeed the x-coordinate
      of a possible curve point). For implementers that *do* perform the
      curve check and do care more about performance than about the
      32-octet communication savings, this would present a disadvantage.
      

      

      The only case where the latter does not incur such a large
      performance hit seems to be in cases where scalar multiplication
      does not use the y-coordinate at all (since then one does not care
      about y' and simply sees whether alpha is a quadratic residue).
      This does however restrict implementation freedom.

      

      If one were to be concerned about implementation attacks, why not
      have people compute a compressed point R':=(x,y') from a received
      uncompressed point R:=(x,y) {this simply requires taking y':=y
      (mod 2), i.e., determining the parity of y} and then do as you
      suggested.

      

      Using uncompressed points gives people two mechanisms for
      preventing invalid point attacks (via curve check or point
      decompression), at slightly higher communication cost (32 octets)
      that seems easy to accept in most TLS applications. Allowing
      freedom to choose either format gives people choice, also on
      communication cost side, at trivial cost of having a single octet
      indicator. 

      

      This leads us back to the representation formats we currently
      have.

      

      Best regards, Rene

      

      ==

      Yes, but uncompressed points are not a security concern in X509,
      but they are in ECDH. Furthermore, the cost of adding compression
      support is very small: it's a square root, a check, and
      potentially flipping the sign. The benefit is that invalid point
      attacks are much harder to carry out.

      

      On 10/22/2014 12:11 PM, Watson Ladd wrote:

    

    

      
On Tue, Oct 21, 2014 at 8:11 AM, Michael StJohns <msj@nthpermutation.com>
        wrote:

        > On 10/21/2014 10:52 AM, Eric Rescorla wrote:

        >

        > https://github.com/tlswg/tls13-spec/issues/80

        >

        > Today we discussed the possibility of requiring support for
        compressed

        > points

        > in TLS 1.3 now that the IPR has expired.

        >

        > Specifically, I propose that for TLS 1.3, we:

        >

        > - Use only compressed points for the existing curves (and
        presumably

        > whatever superior format is defined for the
        CFRG-recommended

        > curves, as appropriate).

        >

        > - Deprecate the Supported Point Formats extension for TLS
        1.3

        >

        >

        > I'm pretty much opposed to the former and I guess by
        extension the latter.

        >

        > There's a very large body of code that doesn't support
        anything except type

        > 0x04(uncompressed) X9.63 point encodings. If you want to
        add support for

        > compressed points (or hybrid compressed), I don't think
        that's necessarily a

        > bad idea, but not at the expense of removing support for
        uncompressed

        > points. If you wanted to remove the supported point format
        extension, I

        > guess you could mandate support for both compressed and
        uncompressed (and

        > hybrid?).

      
There is a large body of code that doesn't support
        TLS 1.3 as well.

        >

        > As a second item, I would estimate the chance we're going
        to see compressed

        > points in X509 certificates as a regular thing prior to
        about 10 years from

        > now as very small, meaning that any general transition to
        EC based suites is

        > going to require uncompressed point support.

      
Yes, but uncompressed points are not a security
        concern in X509, but they are in ECDH. Furthermore, the cost of
        adding compression support is very small: it's a square root, a
        check, and potentially flipping the sign. The benefit is that
        invalid point attacks are much harder to carry out.

      
>

        > Lastly, while the base IPR for point compression seems to
        be no longer of

        > concern, I've still been told to avoid it for a few more
        years due to

        > implementation patents related to compression. I'm not sure
        how worrisome

        > that is, but its one of the reasons that binary curves
        aren't in broader use

        > still.

        >

        > Just my $.02

        >

        > Mike

        >

        >

        >

        > For RFC 4492-bis, we might also consider requiring support
        for compressed

        > points as well as uncompressed (already required) but this
        seems like a

        > separable issue, since it's mostly in service of
        optimization rather than

        > simplicity.

        >

        > What do people think?

        > -Ekr

        >

        >

        >

        >

        >

        >

        >

        > _______________________________________________

        > TLS mailing list

        > TLS@ietf.org

        > https://www.ietf.org/mailman/listinfo/tls

        >

        >

        >

        > _______________________________________________

        > TLS mailing list

        > TLS@ietf.org

        > https://www.ietf.org/mailman/listinfo/tls

        >

        

      

      
--

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

        -- Benjamin Franklin

      

      

      

      
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


    

    

    

    
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

  


--------------020505050207050404070500--


From nobody Wed Oct 22 10:29:42 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A861ACE59 for ; Wed, 22 Oct 2014 10:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRITs0_s7sjc for ; Wed, 22 Oct 2014 10:29:36 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D971ACE84 for ; Wed, 22 Oct 2014 10:29:35 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id n3so1543381wiv.3 for ; Wed, 22 Oct 2014 10:29:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:content-type; bh=MBdohFc5hpUC4Cm2k0SO4nivgf7yf8eKXRUl6qF4Q3o=; b=QlQgw6pgkPUjRuaWhCPBKyVrWgaAW/51Fjleui19TsJ60w2DGu1qfM2YFF2c/zMZGv aHI6aAzmYnuMdiqadDCm2yo/vcSnZL80/6KI1jRPPe38zxapUUKHz+h/KlYf+XGDVj4O DeG4Nm04HtHAswVnONnf+TFHra5wWlZRlYz9YB6wq5mvBGoIhhYoT+/u0J8OyVddT9As aKP7Y5jqyuMaWUafbvJp46KmYHvFcOtOi6CE4G7w83vW6Emh1rzEMnZMde7m2SnYYlLY BY9EcHEtsUpFkSyfQZBrnFHp7YliHLyRzHno5Rtpw0o1fFBt5IymqHUzGoUvT3WZB07G ag6w==
X-Received: by 10.180.104.7 with SMTP id ga7mr7300326wib.1.1413998974142; Wed, 22 Oct 2014 10:29:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.242.39 with HTTP; Wed, 22 Oct 2014 10:28:54 -0700 (PDT)
From: Ryan Carboni 
Date: Wed, 22 Oct 2014 10:28:54 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=f46d04427186910dc50506064a93
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CdIktTJLx_pn3iMMYsm3EGRvchY
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 17:29:38 -0000

--f46d04427186910dc50506064a93
Content-Type: text/plain; charset=UTF-8

>
> The main concern that I have with this approach is that attacks against
> RC4 will only get better and while the attacks may be currently impractical
> against HTTP cookies perhaps there are other usages where the problem may
> be greater.
>
> Pragmatically, implementers will do what is necessary to interoperate, so
> I think something along the lines of what Chris recommends below may be the
> best way forward.    I'm a bit reluctant to bring opportunistic security
> into the discussion at this point, but I think the rest is OK.
>
> Do folks think this is an acceptable way forward?
>
> Thanks,
>
> Joe


This is a common misconception. Cryptography isn't a linear effort. As
knowledge of cryptography improves through research, that knowledge is
applied through the design of future ciphers. This is why MD5 was easily
broken, but only after knowledge had improved. After theoretical attacks on
SHA-1 emerged, people used the trendline of how quickly md5 failed to
determine that SHA-256 will fall in about 5 to 15 years. Thus there was a
SHA-3 hash competition, but it turned out that the trendline failed, the
knowledge on which SHA-256 was built was superior to md5.

This is why SHA-256 will never have a malicious collision, and why RC4 will
never be broken. RC4 is a primitive design and Rivest got lucky in
designing a good cipher when knowledge of cryptography was so poor.
Preimaging the internal state of RC4 based on it's output will be
difficult, partly why the best attack from that direction is around 2^700.

RC4 shouldn't be used in new protocols much like md5, ChaCha8 128-bit
should probably replace RC4, but there aren't many fast ciphers currently
implemented in clients right now. And it will take years for
implementations to spread. It isn't practical to remove RC4 based on using
trendlines of past events when they don't apply in the same situation.

The number of possible permutations that could lead to a given RC4 output
is staggering, once again, the best attack on RC4's output is 2^700.
Attacks do not improve linearly, that is RC4 does not become 2^-10 less
secure each year.


On a minor note, after disabling RC4 and non-forward secrecy cipher suites,
I find my firefox browser negotiates Triple DES with servers with some old
set of cipher suites. I really do wish client side prioritization was
possible.

If you guys really want to disable RC4, why not disable Triple DES? It's
horribly insecure and is certainly "closer" to a break than RC4. It's 2^90
(despite a 168 bit key) at best, particularly with some precomputation
involved.

--f46d04427186910dc50506064a93
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The main=
 concern that I have with this approach is that attacks against=20
RC4 will only get better and while the attacks may be currently=20
impractical against HTTP cookies perhaps there are other usages where=20
the problem may be greater.



Pragmatically, implementers will do what is necessary to interoperate,=20
so I think something along the lines of what Chris recommends below may=20
be the best way forward.=C2=A0 =C2=A0 I'm a bit reluctant to bring oppo=
rtunistic=20
security into the discussion at this point, but I think the rest is OK.



Do folks think this is an acceptable way forward?



Thanks,



Joe

This is a common misconception. Cryptog=
raphy isn't a linear effort. As knowledge of cryptography improves thro=
ugh research, that knowledge is applied through the design of future cipher=
s. This is why MD5 was easily broken, but only after knowledge had improved=
. After theoretical attacks on SHA-1 emerged, people used the trendline of =
how quickly md5 failed to determine that SHA-256 will fall in about 5 to 15=
 years. Thus there was a SHA-3 hash competition, but it turned out that the=
 trendline failed, the knowledge on which SHA-256 was built was superior to=
 md5.

This is why SHA-256 will never have a malicious collision, and=
 why RC4 will never be broken. RC4 is a primitive design and Rivest got luc=
ky in designing a good cipher when knowledge of cryptography was so poor. P=
reimaging the internal state of RC4 based on it's output will be diffic=
ult, partly why the best attack from that direction is around 2^700.
RC4 shouldn't be used in new protocols much like md5, ChaCh=
a8 128-bit should probably replace RC4, but there aren't many fast ciph=
ers currently implemented in clients right now. And it will take years for =
implementations to spread. It isn't practical to remove RC4 based on us=
ing trendlines of past events when they don't apply in the same situati=
on.

The number of possible permutations that could lead t=
o a given RC4 output is staggering, once again, the best attack on RC4'=
s output is 2^700. Attacks do not improve linearly, that is RC4 does not be=
come 2^-10 less secure each year. 


On a minor note, a=
fter disabling RC4 and non-forward secrecy cipher suites, I find my firefox=
 browser negotiates Triple DES with servers with some old set of cipher sui=
tes. I really do wish client side prioritization was possible.

If you guys really want to disable RC4, why not disable Triple DES? I=
t's horribly insecure and is certainly "closer" to a break th=
an RC4. It's 2^90 (despite a 168 bit key) at best, particularly with so=
me precomputation involved.


--f46d04427186910dc50506064a93--


From nobody Wed Oct 22 10:52:52 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD051ACEB3 for ; Wed, 22 Oct 2014 10:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ4ZSswmu2Xs for ; Wed, 22 Oct 2014 10:52:41 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5583D1ACE9E for ; Wed, 22 Oct 2014 10:52:41 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 483872AB109; Wed, 22 Oct 2014 17:52:39 +0000 (UTC)
Date: Wed, 22 Oct 2014 17:52:39 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141022175238.GF19158@mournblade.imrryr.org>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fFGB40ThV1TfxqamcRTLMAl3KAU
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 17:52:51 -0000

On Wed, Oct 22, 2014 at 10:28:54AM -0700, Ryan Carboni wrote:

> This is why SHA-256 will never have a malicious collision, and why RC4 will
> never be broken.

Well, never is a long time, and it is already somewhat broken, in that
the bias in at least firt 256 bytes of output makes fixed plaintexts
transmitted repeatedly under varying keys vulnerable to recovery.

While I would prefer to see RC4 phased out more gradually, I do
not think we can claim that it has not been broken.

So I think that it would be nice if there was some wiggle-room for
opportunistic TLS.  As weak as RC4 might be, it is stronger than
cleartext.  And the published bias attacks don't apply to MTA to
MTA SMTP.  There is no (pairwise) fixed sensitive plaintext at a
fixed offset in every MTA to MTA email transaction.

I have no objections to banning RC4 for "strict" TLS use-cases.

-- 
	Viktor.


From nobody Wed Oct 22 11:15:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71F41ACF18 for ; Wed, 22 Oct 2014 11:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrXBkRIA3mRj for ; Wed, 22 Oct 2014 11:15:13 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0117.outbound.protection.outlook.com [207.46.100.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FA81ACEED for ; Wed, 22 Oct 2014 11:15:13 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 18:15:11 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Wed, 22 Oct 2014 18:15:11 +0000
From: Andrei Popov 
To: Eric Rescorla , "tls@ietf.org" 
Thread-Topic: [TLS] Should we require compressed points
Thread-Index: AQHP7T7GIZmtj79MzkKyCxpOg7rXUJw8aWnQ
Date: Wed, 22 Oct 2014 18:15:11 +0000
Message-ID: <1799fe49d54b4d43acc26778b9265c8a@BL2PR03MB419.namprd03.prod.outlook.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB420;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 037291602B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(199003)(20776003)(19617315012)(4396001)(95666004)(99286002)(64706001)(31966008)(16236675004)(15202345003)(107046002)(107886001)(87936001)(33646002)(74316001)(106356001)(19300405004)(2656002)(40100003)(108616004)(85306004)(76176999)(15975445006)(54356999)(85852003)(122556002)(19580395003)(19580405001)(19609705001)(21056001)(50986999)(92566001)(76576001)(46102003)(76482002)(86362001)(105586002)(106116001)(19625215002)(80022003)(99396003)(86612001)(2501002)(101416001)(120916001)(97736003)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_1799fe49d54b4d43acc26778b9265c8aBL2PR03MB419namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lTZBo7COoKX7pH62RyysxaBJIuY
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 18:15:16 -0000

--_000_1799fe49d54b4d43acc26778b9265c8aBL2PR03MB419namprd03pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QSBmZXcgY29uc2lkZXJhdGlvbnM6DQoNCi0gICAgICAgICAgVGhlIOKAnElQUiBoYXMgZXhwaXJl
ZOKAnSBzdGF0ZW1lbnQgd2lsbCByZXF1aXJlIGxlZ2FsIHZhbGlkYXRpb24gYmVmb3JlIGFuIGlt
cGxlbWVudGVyIGNhbiBiYWtlIHBvaW50IGNvbXByZXNzaW9uIGludG8gcHJvZHVjdHM7DQoNCi0g
ICAgICAgICAgRmV3ZXIgYnl0ZXMgb24gdGhlIHdpcmUvbW9yZSBDUFUgaXMgYSBnb29kIHRyYWRl
b2ZmIGluIHNvbWUgc2NlbmFyaW9zLCBidXQgcHJvYmFibHkgbm90IGluIGV2ZXJ5IHNjZW5hcmlv
Ow0KDQotICAgICAgICAgIFJlcXVpcmluZyBzdXBwb3J0IGZvciBwb2ludCBjb21wcmVzc2lvbiBp
bXBvc2VzIGFkZGl0aW9uYWwgKGV2ZW4gaWYgcmVsYXRpdmVseSBtaW5vciwgaW4gdGhlIHNjYWxl
IG9mIHRoaW5ncykgY29zdCBmb3IgVExTMS4zIGltcGxlbWVudGVycy4NCg0KV2hhdCBhcmUgdGhl
IHJlYXNvbnMgZm9yIGdldHRpbmcgcmlkIG9mIHVuY29tcHJlc3NlZCBwb2ludHM/DQoNCkNoZWVy
cywNCg0KQW5kcmVpDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBP
biBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAyMSwgMjAx
NCA3OjUyIEFNDQpUbzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBbVExTXSBTaG91bGQgd2UgcmVx
dWlyZSBjb21wcmVzc2VkIHBvaW50cw0KDQpodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMt
c3BlYy9pc3N1ZXMvODANCg0KVG9kYXkgd2UgZGlzY3Vzc2VkIHRoZSBwb3NzaWJpbGl0eSBvZiBy
ZXF1aXJpbmcgc3VwcG9ydCBmb3IgY29tcHJlc3NlZCBwb2ludHMNCmluIFRMUyAxLjMgbm93IHRo
YXQgdGhlIElQUiBoYXMgZXhwaXJlZC4NCg0KU3BlY2lmaWNhbGx5LCBJIHByb3Bvc2UgdGhhdCBm
b3IgVExTIDEuMywgd2U6DQoNCi0gVXNlIG9ubHkgY29tcHJlc3NlZCBwb2ludHMgZm9yIHRoZSBl
eGlzdGluZyBjdXJ2ZXMgKGFuZCBwcmVzdW1hYmx5DQogIHdoYXRldmVyIHN1cGVyaW9yIGZvcm1h
dCBpcyBkZWZpbmVkIGZvciB0aGUgQ0ZSRy1yZWNvbW1lbmRlZA0KICBjdXJ2ZXMsIGFzIGFwcHJv
cHJpYXRlKS4NCg0KLSBEZXByZWNhdGUgdGhlIFN1cHBvcnRlZCBQb2ludCBGb3JtYXRzIGV4dGVu
c2lvbiBmb3IgVExTIDEuMw0KDQoNCkZvciBSRkMgNDQ5Mi1iaXMsIHdlIG1pZ2h0IGFsc28gY29u
c2lkZXIgcmVxdWlyaW5nIHN1cHBvcnQgZm9yIGNvbXByZXNzZWQNCnBvaW50cyBhcyB3ZWxsIGFz
IHVuY29tcHJlc3NlZCAoYWxyZWFkeSByZXF1aXJlZCkgYnV0IHRoaXMgc2VlbXMgbGlrZSBhDQpz
ZXBhcmFibGUgaXNzdWUsIHNpbmNlIGl0J3MgbW9zdGx5IGluIHNlcnZpY2Ugb2Ygb3B0aW1pemF0
aW9uIHJhdGhlciB0aGFuDQpzaW1wbGljaXR5Lg0KDQpXaGF0IGRvIHBlb3BsZSB0aGluaz8NCi1F
a3INCg0KDQoNCg0KDQo=

--_000_1799fe49d54b4d43acc26778b9265c8aBL2PR03MB419namprd03pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N
c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw
aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp
Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv
cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3
aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm
aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjI4MDk2MjQ5NjsNCgltc28tbGlz
dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE5OTc4NzIyMjIgNTU0NjA1
Nzg0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5
IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt
Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh
bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs
NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K
QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX
aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm
b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu
b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJn
aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkEgZmV3IGNvbnNpZGVyYXRpb25zOjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl
bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z
by1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSDigJxJUFIgaGFzIGV4cGlyZWTigJ0gc3Rh
dGVtZW50IHdpbGwgcmVxdWlyZSBsZWdhbCB2YWxpZGF0aW9uIGJlZm9yZSBhbiBpbXBsZW1lbnRl
ciBjYW4gYmFrZSBwb2ludCBjb21wcmVzc2lvbiBpbnRvIHByb2R1Y3RzOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6
LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1s
aXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h
biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZld2VyIGJ5dGVzIG9uIHRoZSB3aXJlL21vcmUgQ1BV
IGlzIGEgZ29vZCB0cmFkZW9mZiBpbiBzb21lIHNjZW5hcmlvcywgYnV0IHByb2JhYmx5IG5vdCBp
biBldmVyeSBzY2VuYXJpbzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz
dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEg
bGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0i
Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw
YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5S
ZXF1aXJpbmcgc3VwcG9ydCBmb3IgcG9pbnQgY29tcHJlc3Npb24gaW1wb3NlcyBhZGRpdGlvbmFs
IChldmVuIGlmIHJlbGF0aXZlbHkgbWlub3IsIGluIHRoZSBzY2FsZSBvZiB0aGluZ3MpIGNvc3Qg
Zm9yIFRMUzEuMyBpbXBsZW1lbnRlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0IGFyZSB0aGUgcmVhc29ucyBm
b3IgZ2V0dGluZyByaWQgb2YgdW5jb21wcmVzc2VkIHBvaW50cz88bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8
L2I+RXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDIxLCAy
MDE0IDc6NTIgQU08YnI+DQo8Yj5Ubzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6
PC9iPiBbVExTXSBTaG91bGQgd2UgcmVxdWlyZSBjb21wcmVzc2VkIHBvaW50czxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS90
bHN3Zy90bHMxMy1zcGVjL2lzc3Vlcy84MCI+aHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEz
LXNwZWMvaXNzdWVzLzgwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+VG9kYXkgd2UgZGlzY3Vzc2VkIHRoZSBwb3NzaWJpbGl0eSBvZiByZXF1aXJpbmcg
c3VwcG9ydCBmb3IgY29tcHJlc3NlZCBwb2ludHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluIFRMUyAxLjMgbm93IHRoYXQgdGhlIElQUiBoYXMg
ZXhwaXJlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+U3BlY2lmaWNhbGx5LCBJIHByb3Bvc2UgdGhhdCBmb3IgVExTIDEuMywgd2U6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVXNlIG9u
bHkgY29tcHJlc3NlZCBwb2ludHMgZm9yIHRoZSBleGlzdGluZyBjdXJ2ZXMgKGFuZCBwcmVzdW1h
Ymx5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDsgd2hhdGV2ZXIgc3VwZXJpb3IgZm9ybWF0IGlzIGRlZmluZWQgZm9yIHRoZSBDRlJHLXJl
Y29tbWVuZGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDsgY3VydmVzLCBhcyBhcHByb3ByaWF0ZSkuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gRGVwcmVjYXRlIHRoZSBTdXBwb3J0
ZWQgUG9pbnQgRm9ybWF0cyBleHRlbnNpb24gZm9yIFRMUyAxLjM8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgUkZDIDQ0OTItYmlzLCB3
ZSBtaWdodCBhbHNvIGNvbnNpZGVyIHJlcXVpcmluZyBzdXBwb3J0IGZvciBjb21wcmVzc2VkPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wb2ludHMg
YXMgd2VsbCBhcyB1bmNvbXByZXNzZWQgKGFscmVhZHkgcmVxdWlyZWQpIGJ1dCB0aGlzIHNlZW1z
IGxpa2UgYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+c2VwYXJhYmxlIGlzc3VlLCBzaW5jZSBpdCdzIG1vc3RseSBpbiBzZXJ2aWNlIG9mIG9wdGlt
aXphdGlvbiByYXRoZXIgdGhhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+c2ltcGxpY2l0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBkbyBwZW9wbGUgdGhpbms/PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_1799fe49d54b4d43acc26778b9265c8aBL2PR03MB419namprd03pro_--


From nobody Wed Oct 22 11:27:03 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84EA1ACC86 for ; Wed, 22 Oct 2014 11:26:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yfqa3ATMK0Bg for ; Wed, 22 Oct 2014 11:26:57 -0700 (PDT)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEFEF1ACCEE for ; Wed, 22 Oct 2014 11:26:56 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id d1so2160151wiv.12 for ; Wed, 22 Oct 2014 11:26:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LlHAUdIhvW2GXkjbTSNTTa1PdYoluiUQtLk7fOKJvX4=; b=YW24R76weUQf1DsO6juGzF5AsH0ZKEILLQ1IYivsRUZGlgcYaGrXDlqipRsDK5Q1dT R9Fyn/whI4uw1D8stPAxy6ID9QZXSvPt29YjCUq949pXRnkoxjIJUVf1bAgdzDBM6I6g G5tfoz+PUvEBdkAgiPA8blJkgo+TAynZ4D5zQ7FvrLGe88dHhwWL6iyORZmI7Qu21lOi 3t6TN5BqpAWZ7YmXUbiRE9dgbgvbuysT1wESFgFP0AYWeSLrK7FbxYmNnjeJicDH+PHn L+YpKp02Hw4plgKY6+5OER214Eo76R1mmKt26KACjeVsYxjFZDnv7uLKUo8mrQmdXcXm 4t3Q==
X-Gm-Message-State: ALoCoQkvee6/dTQ+2eM5tuRiw7sH2vosMLHWId4j5Eruoa505T8mKQyfzjupwWFiVpgXStVqOFqX
X-Received: by 10.194.242.4 with SMTP id wm4mr52105076wjc.61.1414002415537; Wed, 22 Oct 2014 11:26:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Wed, 22 Oct 2014 11:26:15 -0700 (PDT)
In-Reply-To: <1799fe49d54b4d43acc26778b9265c8a@BL2PR03MB419.namprd03.prod.outlook.com>
References:  <1799fe49d54b4d43acc26778b9265c8a@BL2PR03MB419.namprd03.prod.outlook.com>
From: Eric Rescorla 
Date: Wed, 22 Oct 2014 20:26:15 +0200
Message-ID: 
To: Andrei Popov 
Content-Type: multipart/alternative; boundary=089e01419af6b0c5fe0506071717
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IPiGNI2MVJFFT2Yp_BeumP-pZdc
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 18:26:59 -0000

--089e01419af6b0c5fe0506071717
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 22, 2014 at 8:15 PM, Andrei Popov 
wrote:

>  A few considerations:
>
> -          The =E2=80=9CIPR has expired=E2=80=9D statement will require l=
egal validation
> before an implementer can bake point compression into products;
>
> -          Fewer bytes on the wire/more CPU is a good tradeoff in some
> scenarios, but probably not in every scenario;
>
> -          Requiring support for point compression imposes additional
> (even if relatively minor, in the scale of things) cost for TLS1.3
> implementers.
>
>
>
> What are the reasons for getting rid of uncompressed points?
>
>
Really what I want is to get rid of point negotiation, because it's yet
another
point of complexity and it's not universally implemented anyway. Given that
people seem to think that compressed points are better, I figured that was
the way to go. If people prefer to just require uncompressed points (at
least for the existing X9.63 curves) I could certainly live with that.

-Ekr


>
>

>

>
 Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Tuesday, October 21, 2014 7:52 AM
> *To:* tls@ietf.org
> *Subject:* [TLS] Should we require compressed points
>
>
>
> https://github.com/tlswg/tls13-spec/issues/80
>
>
>
> Today we discussed the possibility of requiring support for compressed
> points
>
> in TLS 1.3 now that the IPR has expired.
>
>
>
> Specifically, I propose that for TLS 1.3, we:
>
>
>
> - Use only compressed points for the existing curves (and presumably
>
>   whatever superior format is defined for the CFRG-recommended
>
>   curves, as appropriate).
>
>
>
> - Deprecate the Supported Point Formats extension for TLS 1.3
>
>
>
>
>
> For RFC 4492-bis, we might also consider requiring support for compressed
>
> points as well as uncompressed (already required) but this seems like a
>
> separable issue, since it's mostly in service of optimization rather than
>
> simplicity.
>
>
>
> What do people think?
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>

--089e01419af6b0c5fe0506071717
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 22, 2014 at 8:15 PM, Andrei Popov <Andrei.Popov@m=
icrosoft.com> wrote:











A few considerations:<=
/u>


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
The =E2=80=9CIPR has=
 expired=E2=80=9D statement will require legal validation before an impleme=
nter can bake point compression into products;


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
Fewer bytes on the w=
ire/more CPU is a good tradeoff in some scenarios, but probably not in ever=
y scenario;


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
Requiring support fo=
r point compression imposes additional (even if relatively minor, in the sc=
ale of things) cost for TLS1.3 implementers.


=C2=A0


What are the reasons for =
getting rid of uncompressed points?



Rea=
lly what I want is to get rid of point negotiation, because it's yet an=
other
point of complexity and it's not universally implemente=
d anyway. Given that
people seem to think that compressed points =
are better, I figured that was
the way to go. If people prefer to=
 just require uncompressed points (at
least for the existing X9.6=
3 curves) I could certainly live with that.

-Ekr
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=



Cheers,


=C2=A0


Andrei


=C2=A0


From: TLS [m=
ailto:tls-bounces=
@ietf.org]
On Behalf Of Eric Rescorla

Sent: Tuesday, October 21, 2014 7:52 AM

To: tls@ietf.org

Subject: [TLS] Should we require compressed points


=C2=A0




https://github.com/tlswg/tls13-spec/issues/80




=C2=A0






Today we discussed the possibility of requiring supp=
ort for compressed points






in TLS 1.3 now that the IPR has expired.






=C2=A0






Specifically, I propose that for TLS 1.3, we:=







=C2=A0






- Use only compressed points for the existing curves=
 (and presumably






=C2=A0 whatever superior format is defined for the C=
FRG-recommended






=C2=A0 curves, as appropriate).






=C2=A0






- Deprecate the Supported Point Formats extension fo=
r TLS 1.3






=C2=A0






=C2=A0






For RFC 4492-bis, we might also consider requiring s=
upport for compressed






points as well as uncompressed (already required) bu=
t this seems like a






separable issue, since it's mostly in service of=
 optimization rather than






simplicity.






=C2=A0






What do people think?






-Ekr






=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0














--089e01419af6b0c5fe0506071717--


From nobody Wed Oct 22 11:37:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4DF1ACF9B for ; Wed, 22 Oct 2014 11:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ppi0NhuaFqu7 for ; Wed, 22 Oct 2014 11:37:18 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1081ACF94 for ; Wed, 22 Oct 2014 11:37:18 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id d1so2178054wiv.14 for ; Wed, 22 Oct 2014 11:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:content-type; bh=4C8Y8XgZ7SQb6+kykeMv+orE17iiPLsfjMD1Y1fKzjc=; b=gm+pKNrN1UlRfwMjVF9D9DbIvdbWnCadzGfZYbi5AKF3+akl3oyGgMK+m4db1CUQ7+ IEtDaKuUivDA5BGGVS4NY2zTTTrf2UviCKOUCCyteY6uz4fXJixoddHCU0XYpEKHmH87 j7iv6W4iWWn68D7tfGfUuoDPwHvorSXEZ+YCN2NR+IWrzqa1IVB7ABSUi4vDvEtYD4mv G1yRLJvgXFaLWsfvEJbBjhz/oLialabrpuVmsL2gTHrIZdE2G5O8YXNlWbJVsjkP33nS 321cOeSBAyifyPtmDl6pUO/+GZEmcFt7rS9T1rHgD5VcPWH1QFLofFLOsb9Z1zm6QG91 UsVA==
X-Received: by 10.194.209.230 with SMTP id mp6mr631wjc.2.1414003036626; Wed, 22 Oct 2014 11:37:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.242.39 with HTTP; Wed, 22 Oct 2014 11:36:36 -0700 (PDT)
From: Ryan Carboni 
Date: Wed, 22 Oct 2014 11:36:36 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b3a8c08b5a5750506073c3c
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/t30Nq6nw3fc-qae3wCSdCWvNIpU
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 18:37:22 -0000

--047d7b3a8c08b5a5750506073c3c
Content-Type: text/plain; charset=UTF-8

>
> Well, never is a long time, and it is already somewhat broken, in that
> the bias in at least firt 256 bytes of output makes fixed plaintexts
> transmitted repeatedly under varying keys vulnerable to recovery.


Yes, there's obvious issues with RC4's key-schedule. I visit some websites
as much as 2^15 times a year, or 2^(6.5) times a day, mostly forums of
interest. The bias attack at best can break 2^30. Or to put it in better
perspective:

http://googleonlinesecurity.blogspot.com/2013/11/a-roster-of-tls-cipher-suites-weaknesses.html

"The best, known attack against using RC4 with HTTPS involves causing a
browser to transmit many HTTP requests -- each with the same cookie -- and
exploiting known biases in RC4 to build an increasingly precise probability
distribution for each byte in a cookie. However, the attack needs to see on
the order of 10 billion copies of the cookie in order to make a good guess.
This involves the browser sending ~7TB of data. In ideal situations, this
requires nearly three months to complete."

RC4 should be fully deprecated... in 2020.

--047d7b3a8c08b5a5750506073c3c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Well, ne=
ver is a long time, and it is already somewhat broken, in that

the bias in at least firt 256 bytes of output makes fixed plaintexts

transmitted repeatedly under varying keys vulnerable to recovery.

Yes, there's obvious issues with RC4's key-s=
chedule. I visit some websites as much as 2^15 times a year, or 2^(6.5) tim=
es a day, mostly forums of  interest. The bias attack at best can break 2^3=
0. Or to put it in better perspective:
=C2=A0http://googleonlinesecurity.blogspot.com/2013/11/a-roster-of-tls-ciphe=
r-suites-weaknesses.html 

"The best, known attack against u=
sing RC4 with HTTPS involves causing a=20
browser to transmit many HTTP requests -- each with the same cookie --=20
and exploiting known biases in RC4 to build an increasingly precise=20
probability distribution for each byte in a cookie. However, the attack=20
needs to see on the order of 10 billion copies of the cookie in order to
 make a good guess. This involves the browser sending ~7TB of data. In=20
ideal situations, this requires nearly three months to complete."
<=
br>
RC4 should be fully deprecated... in 2020.


--047d7b3a8c08b5a5750506073c3c--


From nobody Wed Oct 22 11:37:30 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64521ACF9E for ; Wed, 22 Oct 2014 11:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzNPIzaFCVlI for ; Wed, 22 Oct 2014 11:37:27 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944951ACF9C for ; Wed, 22 Oct 2014 11:37:26 -0700 (PDT)
Received: by mail-lb0-f171.google.com with SMTP id z12so3367873lbi.16 for ; Wed, 22 Oct 2014 11:37:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4xL5PbZ6jeweF3vHu5L0L+bQrGkleFIK46m+W1sGE30=; b=X/Dj6tR6GmPkWwrmTzf0Vz+bj7kFm0vQAGU6jfQxdmL83vcbKCSdFdids95ZE+98C5 M2l6Ykq0ZOt9JR0DA+WcACAYBg15532kmgsB93Rurs9Sdoakc8E+C+198Q0BwUhPjLUS SfpNWBqLpP2MRkcXGIr6r/YpfaInWqw+MSWIMkgGiSdaOwR+iIMIRJUDiy8VsyaOhnRw WmxirODuXwj0nU9EMNEX3G+Xkue/Vt5IWl6ciZcDaBG/0PB9T9g+7GIwWnjfR4qQbVuw unngWSl7/yZpYLAj0Nhxi55b7uD5dztomuAbyBLbjCplj/1BzJ/EN9TonxXeMFK7HCaC 9Z9g==
MIME-Version: 1.0
X-Received: by 10.152.26.195 with SMTP id n3mr10950164lag.43.1414003044824; Wed, 22 Oct 2014 11:37:24 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Wed, 22 Oct 2014 11:37:24 -0700 (PDT)
In-Reply-To: 
References:  <20141022151819.44A791AF05@ld9781.wdf.sap.corp> 
Date: Wed, 22 Oct 2014 11:37:24 -0700
Message-ID: 
From: Martin Thomson 
To: Joseph Salowey 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F2QPNWstjtz1fDh4lWykgbILRck
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 18:37:29 -0000

On 22 October 2014 09:51, Joseph Salowey  wrote:
> If we are going to remove the certificate request I think we will need to
> communicate this information in the handshake itself or perhaps have a
> "reconnection request".

I'd like to be more explicit about algorithm support in general here,
and I don't think that binding authentication methods into the cipher
suite selection is going to be the best way to do this given the
proposals we have on the table regarding proof-of-identity here.

The thought here was that the application layer knows about the need
for authentication and can provide the reconnection request (a la
draft-..-cant).

We're also not saying that it's end-of-the-line for authentication
within TLS.  It was shown that it was trivial to add mid-session
authentication, but the concerns were related more to the way that
interacts with users of TLS.

Thus, at least in my read of this, we are willing to punt on this for
now, and pursue it separately.  That helps us get core use cases for a
simpler TLS 1.3 complete earlier, which I think is a net gain.  I
think that a relatively small amendment could be used to add
Certificate and CertificateVerify messages to Update at some later
point if we convinced ourselves that the implications were manageable.


From nobody Wed Oct 22 11:42:48 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5481ACFA1 for ; Wed, 22 Oct 2014 11:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqFHrOQJSnp1 for ; Wed, 22 Oct 2014 11:42:41 -0700 (PDT)
Received: from mx205.easyname.com (mx205.easyname.com [212.232.28.126]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857F01ACFC2 for ; Wed, 22 Oct 2014 11:42:41 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xh0rl-00044l-25; Wed, 22 Oct 2014 20:42:39 +0200
Message-ID: <5447FA87.40007@fussenegger.info>
Date: Wed, 22 Oct 2014 20:42:15 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ryan Carboni , "tls@ietf.org" 
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070004000802040608090805"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bqQtPLTsLF79yz_SzAc6v8ngyQU
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 18:42:45 -0000

This is a cryptographically signed message in MIME format.

--------------ms070004000802040608090805
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

I noticed that you all try to dictate your believes of security to=20
others, which is actually very interesting to read so please don't stop=20
(there's **really** no sarcasm in this sentence, but maybe you should=20
rename the thread then because this discussion is otherwise not going=20
anywhere). But you just mentioned a *very* important thing: 128-bit are=20
sufficient today for generic web applications.

Do we want a fully encrypted web? **Yes!**
When do we want it? **Now!**

The essence of my previous message (partly quoted below) was, that it is =

important to ensure within the RFC that a ticket that is storing the=20
state of a SUPER-CRYPTO-9999 cipher isn't going to be encrypted with a=20
GENERIC-CIPHER-128 key. This would simply downgrade the security of the=20
whole agreed upon cipher. But on the other hand if an administrator=20
decided that his web service is only delivering cat photos and that=20
GENERIC-CRYPTO-128 is sufficient in terms of computing power for his=20
server and for his clients, than it doesn't make sense to encrypt the=20
ticket with SUPER-CRYPTO-9999.

Of course if the same administrator decided to support both,=20
GENERIC-CRYPTO-128 and SUPER-CRYPTO-9999, then he'll require the=20
SUPER-CRYPTO-9999 for all tickets. Viktor Dukhovni already mentioned=20
that OpenSSL is actually supporting different key strengths, but for=20
instance nginx isn't exposing this setting to administrators. But the=20
RFC would most certainly compel them to do so in the future, which is a=20
good thing. After all, the cat-photo-admin may continue to use fast and=20
insecure ciphers (but still protecting clients and his services from=20
script kiddies) and the nice whistleblower from our neighborhood may use =

the best available cipher available.

Rich Salz said that the RFC should stay silent on which crypto to use=20
and I agree for above reasons and everything you guys brought up.=20
Stating that crypto-X is sufficiently secure is like saying that god is=20
for real; maybe it is true but science and research will eventually=20
prove the opposite in the future. I stated that (the former not the=20
latter, I'd never say such a thing) and made a mistake by doing so. But=20
I hope that this message clarifies my intentions and also that some of=20
you have an opinion about the actual proposal of mine.

Regards
Richard

On 10/22/2014 6:44 PM, Ryan Carboni wrote:
>
> From: "Richard Fussenegger, BSc"
>
>     [*] Better would be 'from all ciphers in use' otherwise one ends
>     up with
>     a (insert ridiculous high value here) bit key while only using 128 =
bit
>     ciphers in the configuration. Dropping the key if a new stronger
>     configuration is loaded seems like a good idea to me at this
>     point. I'm
>     looking at this from a performance perspective and glimpsing over
>     to the
>     fact that the cryptography community agrees that 128 bit security w=
ill
>     be enough for the next 10 to 20 years.[2] I really can't tell if th=
is
>     would be problematic from an implementation point of view. I think
>     that
>     single hosts won't have a problem here and I guess that it wouldn't=
 be
>     for clusters as well. The cluster configuration should be in sync
>     but it
>     could become a problem if one node has a differing configuration (f=
or
>     whatever reason). What opinion/insights do you have on this?
>
>
>  Quantum computers are reaching 512-qubits now.=20
> http://www.bbc.com/news/science-environment-27632140
>
> Quantum cryptography would result in key-sizes effectively being=20
> halved, and in 15 to 40 years a quantum computer could potentially be=20
> built by a nationstate to enhance known cryptographic attacks and=20
> reduce keyspaces substantially.
>
> It's unlikely though that the NSA will devote quantum computing to=20
> breaking the encryption of cat videos.
>
> I suggest an advisory that for unauthenticated encryption, 128-bits=20
> are used, and for authenticated encryption 256-bits or more are used.=20
> The only issue is that browsers tell you the whole page is encrypted=20
> the same way even though elements of the page use different sorts of=20
> encryption than the body of the page.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



--------------ms070004000802040608090805
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjIxODQyMTVaMCMGCSqGSIb3DQEJBDEWBBQ2MQBJBQfgZsQmmLdnxNTo2RWmmDBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEAzfJThsl+1VXIUDsFYmKsj1Jb3IF4
WVZqURNDYYekJPhNxArJtDsC6+xB7VlWKY2p1V1rN0Koq1/awnze+PY9MM9TD7BesAB3/HIy
wbQeU/pVI6JgpAJqTmoYLGIoBhlc1ItOHr8NkN8I5eBkSV5FcV86eucw9lF70b/leFOUqfrK
TJ3DPMF1YRir7FbQWIqv4yq5GRpqdRS1OV7mSA8mzhYe5BEHOJMj0h5R0/8zXMTtsikwtq/u
EBsDbAIBBRN9hItJAXjKu6bRFNa8iYHbO0+G0LbogYk7CbuQn3Phkaj8Mo//aZDuQO1m3Hj/
gYUkXMQ1IqlxllWZAlW9qaTgfQAAAAAAAA==
--------------ms070004000802040608090805--


From nobody Wed Oct 22 11:46:13 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E613C1ACFC4 for ; Wed, 22 Oct 2014 11:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.444
X-Spam-Level: 
X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7xPCqacmUDa for ; Wed, 22 Oct 2014 11:46:09 -0700 (PDT)
Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A2B091ACFB9 for ; Wed, 22 Oct 2014 11:46:09 -0700 (PDT)
Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 64610360078 for ; Wed, 22 Oct 2014 11:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=W3h+diJhhDvRUhheB297X7S Pfek=; b=y5EVjW6iPMsd1xhQ40dr/279e5d49FeyEETWYqwY6Q06ULV/7qBR3cR T1H6f+qgjz4t5aLYXhm+oCXLuI4huXGV3y1jlWfNFNDmLk6QyVnA0K6cV7nS8B0p iQK2G0wB1hLe+jjGYe+ln0AQPlDANk2sUNdrDXX1cMKj+KGqU+8A=
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 19FCE360075 for ; Wed, 22 Oct 2014 11:46:08 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id m15so4378970wgh.26 for ; Wed, 22 Oct 2014 11:46:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.181.8.98 with SMTP id dj2mr7633689wid.70.1414003567820; Wed, 22 Oct 2014 11:46:07 -0700 (PDT)
Received: by 10.216.32.135 with HTTP; Wed, 22 Oct 2014 11:46:07 -0700 (PDT)
In-Reply-To: <20141020235832.GK19158@mournblade.imrryr.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org>
Date: Wed, 22 Oct 2014 13:46:07 -0500
Message-ID: 
From: Nico Williams 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cNIV1DT6BFDsrqhEfYYNg9kEyys
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 18:46:12 -0000

On Mon, Oct 20, 2014 at 6:58 PM, Viktor Dukhovni  wrote:
> On Mon, Oct 20, 2014 at 11:39:31PM +0200, Manuel P?gouri?-Gonnard wrote:
>> > The RFC should clarify that the negotiated cipher **MUST** be honored
>> > when encrypting the state that will be sent to the client. [1]
>
> I am having trouble parsing the original suggestion above.

Even parsed as the context implies, there's problems: a) the client
can't verify that the ticket is encrypted in any given cipher, b) why
on Earth should the server let the client choose what cipher is used
for the Ticket?, c) given (a), what is to be gained by any party from
the server using the client's desired cipher for encrypting the
ticket?

>> While I'm sympathetic with the goal, I'm afraid that will complicate
>> implementations more than necessary. How about requiring to use a key length at
>> least a high as the highest supported ciphersuite instead?

This is just as silly.  The server should choose what cipher to use, full stop.

> Does it mean (as I think you're saying) that session tickets MUST
> be encrypted with the session's negotiated ciphersuite?  That seems
> rather unmanageable.  A single sufficiently strong key is likely
> far more realistic.

Yes.

> With keys for clusters of servers rotated by code external to the
> TLS library, asking for a key for every algorith/size is impractical.

One would derive keys for all ciphers from a single cluster master
key.  Nonetheless, it's just plain silly to let the client/connection
dictate how to encrypt the ticket -- that's the server's prerogative.

Nico
--


From nobody Wed Oct 22 11:47:16 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B8F1ACFC9 for ; Wed, 22 Oct 2014 11:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2rPrN3-1DDO for ; Wed, 22 Oct 2014 11:47:12 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961EA1ACFCD for ; Wed, 22 Oct 2014 11:47:10 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id mc6so3512596lab.2 for ; Wed, 22 Oct 2014 11:47:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MJVPHyGDQi1haQFuD0Xt8iXR7D6GUqjuedYrlgDDh+w=; b=04u1mKUZaRZpPV1D/HETYtm+JUQ1a36YGIWZwNBv7PsIdLfnfhTo4CJqFg490dQ5yH RXyBNZHaBTHMGjMCQbnRRUYwAcIoxYyNEgcO4rNb71chd+OZ+8TuNGtLbHxAcDvQHP3n 2W7q9gxuw9V4dZylBHt7XppuZLOyKk8VJWT242LP6CogHbXmH5oyZpa//jwG+lgBf668 asxQBrRsuWX5JL2Lqera0sUFBNu2+owZcX9f/fU4ezOW2c9dwfhvrn0rbhD3tX+9oGx9 ORrrg12ah9+ZFwaX50VND8BSCT1tXyFw8r3+qXWApVIPzFslSUS3jdoRNRYJqnIQY6Yu y80A==
MIME-Version: 1.0
X-Received: by 10.152.116.68 with SMTP id ju4mr43426758lab.13.1414003628875; Wed, 22 Oct 2014 11:47:08 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Wed, 22 Oct 2014 11:47:08 -0700 (PDT)
In-Reply-To: 
References:  <1799fe49d54b4d43acc26778b9265c8a@BL2PR03MB419.namprd03.prod.outlook.com> 
Date: Wed, 22 Oct 2014 11:47:08 -0700
Message-ID: 
From: Martin Thomson 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fQZTb2kTbUicPpoU_F2Mjnxmfew
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 18:47:14 -0000

On 22 October 2014 11:26, Eric Rescorla  wrote:
>> What are the reasons for getting rid of uncompressed points?
>
>
> Really what I want is to get rid of point negotiation, because it's yet
> another
> point of complexity and it's not universally implemented anyway. Given that
> people seem to think that compressed points are better, I figured that was
> the way to go. If people prefer to just require uncompressed points (at
> least for the existing X9.63 curves) I could certainly live with that.

Yep, and I'll note that 32 octets isn't a trivial amount of space in a
handshake.  We're particularly space constrained here.  If that's 32
octets more of application data I'd have available, I suspect that
another compressed HTTP/2 request - or a good proportion of one -
could fit in that space (for a 0 RTT mode in particular).


From nobody Wed Oct 22 11:47:51 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D111ACFD3 for ; Wed, 22 Oct 2014 11:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoY0HyJ23i6J for ; Wed, 22 Oct 2014 11:47:43 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E651ACFDE for ; Wed, 22 Oct 2014 11:47:42 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id m15so4381973wgh.26 for ; Wed, 22 Oct 2014 11:47:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1qribWnRGqVJhf6yWqqdqOyo/zBjcYFVIlkcspXk1Mg=; b=RymaolG/Eb9YA5o07c8dzmduPfxDTwv6BT968meRAIVCFQhn5JxntHzqLf1co32RJT Kny6UQP7K/YQMhAVcjFUgQRAs0+1uakAi5nOHyW+yVEYESGRl5fiPR+4bks4xMpnGjJt XoGxL7v7C8dlPEVs7nBCPQofgSRkRIrkIJazRZW+7u8s6UXKREUl5muxCVZWCaD2SUho hM53H5dGoykFQxQMtomfCtqjr06DEs9BMdHp/ckZzWvcOexDrTMGVxQx+I+QMUb92puh QqXGTlLItF7/++EwZS2tcZ4/9+CKKOjgwbyJUMljf8stl3NLtpaTn7Vl3rSJn0o65OTH EB4A==
X-Received: by 10.180.104.7 with SMTP id ga7mr7746698wib.1.1414003661539; Wed, 22 Oct 2014 11:47:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.242.39 with HTTP; Wed, 22 Oct 2014 11:47:01 -0700 (PDT)
In-Reply-To: <5447FA87.40007@fussenegger.info>
References:  <5447FA87.40007@fussenegger.info>
From: Ryan Carboni 
Date: Wed, 22 Oct 2014 11:47:01 -0700
Message-ID: 
To: Richard Fussenegger 
Content-Type: multipart/alternative; boundary=f46d04427186f5108c050607614a
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/z1HsQ0OrJh4sMQ53A6BLDHt6asE
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 18:47:48 -0000

--f46d04427186f5108c050607614a
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 22, 2014 at 11:42 AM, Richard Fussenegger <
richard@fussenegger.info> wrote:

> I noticed that you all try to dictate your believes of security to others
>
>
It's all speculative really.

--f46d04427186f5108c050607614a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 22, 2014 at 11:42 AM, Richard Fussenegger <richard@=
fussenegger.info> wrote:
I =
noticed that you all try to dictate your believes of security to others
=


It's all speculative really. 
<=
/div>



--f46d04427186f5108c050607614a--


From nobody Wed Oct 22 11:52:53 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658211ACF08 for ; Wed, 22 Oct 2014 11:52:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.399
X-Spam-Level: 
X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTeEKkXx3b7f for ; Wed, 22 Oct 2014 11:52:49 -0700 (PDT)
Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1581ACFE2 for ; Wed, 22 Oct 2014 11:52:49 -0700 (PDT)
Received: by mail-yh0-f42.google.com with SMTP id t59so4047201yho.29 for ; Wed, 22 Oct 2014 11:52:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UsOMh5Dp5Z1NeaX1yKJPDnxw0yQsXuHPuTKnydADc/E=; b=OPJ02rB9VnngLGUW0RC7X8WzNqd1zW7VLvoY4wYwF311+q8r/LL6Jc2ewJG81SsKXU B/Plnr2cs4pdfJ2xO1qyVmQoOH/6mn2MySdoMwFPvLiGDhpU1Iu4NRFoTa5jzabTCXw4 Rczc/tk88wOqaE/1OUY2dV2dEw4RnGBOwrG3neM0KU3Ic6TbwTVstJXfWgrncXwK/UEd eifFNZqyf+z+KGM5FORbtBoMp6DX+BBAoXQRD/YDT5n4jovlCy+l6D8V02yGUFAruIIc uz084dw34lE3pWLBi/cus0AhproCaIkEPnlGrAr+vhlIPrbUhcPi7sqFuyU4m4voZxkX Qk9g==
MIME-Version: 1.0
X-Received: by 10.236.103.170 with SMTP id f30mr143358yhg.4.1414003968675; Wed, 22 Oct 2014 11:52:48 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Wed, 22 Oct 2014 11:52:48 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Wed, 22 Oct 2014 11:52:48 -0700 (PDT)
In-Reply-To: <5447E307.3010104@gmail.com>
References:  <544677AE.4000005@nthpermutation.com>  <5447E307.3010104@gmail.com>
Date: Wed, 22 Oct 2014 11:52:48 -0700
Message-ID: 
From: Watson Ladd 
To: Rene Struik 
Content-Type: multipart/alternative; boundary=001a113321ae4396d00506077432
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/l0zc7ad-0tIX6sFtMBlGE4SOW_w
Cc: tls@ietf.org
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 18:52:52 -0000

--001a113321ae4396d00506077432
Content-Type: text/plain; charset=UTF-8

On Oct 22, 2014 10:02 AM, "Rene Struik"  wrote:
>
> Hi Watson:
>
> I do not understand your statement below: the cost of "decompressing"
points may be not that insignificant and, depending on application, one
might rather send uncompressed points instead.
>
> For simplicity, let us assume a short-Weierstrass curve E with defining
equation y^2 = x^3 + a x + b (mod p). (A similar argument holds for other
curves, of course.)
>
> If one receives an uncompressed alleged point R:=(x,y), one has to check
whether this is indeed on the curve E. This comes roughly at cost 2S+1M
(where S=squaring; M=multiply).
> If one receives a compressed point R':=(x,y') and requires the
corresponding uncompressed point R, one has to compute a solution y to the
equation y^2=alpha, where alpha:=x^3+ax+b (mod p) and (if there is a
solution) pick y or p-y, depending on the binary value y'. This comes at
roughly cost 1S + 1M+1SQRT (where SQRT=square root).
>
> The trade-off here is that point compression slightly saves on
communication bandwidth, whereas it does increase computational cost of
scalar multiplies.
> {Rough ballpark for 256-bit curve: 64 octet uncompressed point vs. 32
octet compressed point; curve check uncompressed point roughly <0.2% cost
scalar multiply vs. ~10% cost scalar multiply (based on figures I have seen
floating around on the cfrg mailing list).}
>
> Your suggested "security concern" seems to be that implementers will
somehow not perform the curve check (why?) and that, by using point
compression, you simply enforce it indirectly (since recomputing the
uncompressed point from the compressed one includes checking whether the
x-value is indeed the x-coordinate of a possible curve point). For
implementers that *do* perform the curve check and do care more about
performance than about the 32-octet communication savings, this would
present a disadvantage.

Ask Bouncycastle, Apple, and Go why they don't do this check. (Bouncycastle
fixed it). The fact is implementations are exploitable as a result of
taking shortcuts not revealed in ordinary testing.

Furthermore, x coordinate only is adequate for ECDH and was suggested in
the original ECC paper.

>
> The only case where the latter does not incur such a large performance
hit seems to be in cases where scalar multiplication does not use the
y-coordinate at all (since then one does not care about y' and simply sees
whether alpha is a quadratic residue). This does however restrict
implementation freedom.

Brier - Joyce is also slower then table based fixed window methods.
Furthermore,  not all curves in TLS are twist secure.
>
> If one were to be concerned about implementation attacks, why not have
people compute a compressed point R':=(x,y') from a received uncompressed
point R:=(x,y) {this simply requires taking y':=y (mod 2), i.e.,
determining the parity of y} and then do as you suggested.

They could validate the received point instead. Why decompress when you
don't have to?
>
> Using uncompressed points gives people two mechanisms for preventing
invalid point attacks (via curve check or point decompression), at slightly
higher communication cost (32 octets) that seems easy to accept in most TLS
applications. Allowing freedom to choose either format gives people choice,
also on communication cost side, at trivial cost of having a single octet
indicator.
>
> This leads us back to the representation formats we currently have.
>
> Best regards, Rene
>
> ==
>
> Yes, but uncompressed points are not a security concern in X509, but they
are in ECDH. Furthermore, the cost of adding compression support is very
small: it's a square root, a check, and potentially flipping the sign. The
benefit is that invalid point attacks are much harder to carry out.
>
> On 10/22/2014 12:11 PM, Watson Ladd wrote:
>>
>> On Tue, Oct 21, 2014 at 8:11 AM, Michael StJohns 
wrote:
>> > On 10/21/2014 10:52 AM, Eric Rescorla wrote:
>> >
>> > https://github.com/tlswg/tls13-spec/issues/80
>> >
>> > Today we discussed the possibility of requiring support for compressed
>> > points
>> > in TLS 1.3 now that the IPR has expired.
>> >
>> > Specifically, I propose that for TLS 1.3, we:
>> >
>> > - Use only compressed points for the existing curves (and presumably
>> > whatever superior format is defined for the CFRG-recommended
>> > curves, as appropriate).
>> >
>> > - Deprecate the Supported Point Formats extension for TLS 1.3
>> >
>> >
>> > I'm pretty much opposed to the former and I guess by extension the
latter.
>> >
>> > There's a very large body of code that doesn't support anything except
type
>> > 0x04(uncompressed) X9.63 point encodings. If you want to add support
for
>> > compressed points (or hybrid compressed), I don't think that's
necessarily a
>> > bad idea, but not at the expense of removing support for uncompressed
>> > points. If you wanted to remove the supported point format extension, I
>> > guess you could mandate support for both compressed and uncompressed
(and
>> > hybrid?).
>>
>> There is a large body of code that doesn't support TLS 1.3 as well.
>> >
>> > As a second item, I would estimate the chance we're going to see
compressed
>> > points in X509 certificates as a regular thing prior to about 10 years
from
>> > now as very small, meaning that any general transition to EC based
suites is
>> > going to require uncompressed point support.
>>
>> Yes, but uncompressed points are not a security concern in X509, but
they are in ECDH. Furthermore, the cost of adding compression support is
very small: it's a square root, a check, and potentially flipping the sign.
The benefit is that invalid point attacks are much harder to carry out.
>>
>> >
>> > Lastly, while the base IPR for point compression seems to be no longer
of
>> > concern, I've still been told to avoid it for a few more years due to
>> > implementation patents related to compression. I'm not sure how
worrisome
>> > that is, but its one of the reasons that binary curves aren't in
broader use
>> > still.
>> >
>> > Just my $.02
>> >
>> > Mike
>> >
>> >
>> >
>> > For RFC 4492-bis, we might also consider requiring support for
compressed
>> > points as well as uncompressed (already required) but this seems like a
>> > separable issue, since it's mostly in service of optimization rather
than
>> > simplicity.
>> >
>> > What do people think?
>> > -Ekr
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>> >
>> >
>> >
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>> >
>>
>> --
>> "Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
>> -- Benjamin Franklin
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
> email: rstruik.ext@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

--001a113321ae4396d00506077432
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Oct 22, 2014 10:02 AM, "Rene Struik" <rstruik.ext@gmail.com> wrote:

>

> Hi Watson:

>

> I do not understand your statement below: the cost of "decompress=
ing" points may be not that insignificant and, depending on applicatio=
n, one might rather send uncompressed points instead.

>

> For simplicity, let us assume a short-Weierstrass curve E with definin=
g equation y^2 =3D x^3 + a x + b (mod p). (A similar argument holds for oth=
er curves, of course.)

>

> If one receives an uncompressed alleged point R:=3D(x,y), one has to c=
heck whether this is indeed on the curve E. This comes roughly at cost 2S+1=
M (where S=3Dsquaring; M=3Dmultiply).

> If one receives a compressed point R':=3D(x,y') and requires t=
he corresponding uncompressed point R, one has to compute a solution y to t=
he equation y^2=3Dalpha, where alpha:=3Dx^3+ax+b (mod p) and (if there is a=
 solution) pick y or p-y, depending on the binary value y'. This comes =
at roughly cost 1S + 1M+1SQRT (where SQRT=3Dsquare root).

>

> The trade-off here is that point compression slightly saves on communi=
cation bandwidth, whereas it does increase computational cost of scalar mul=
tiplies.

> {Rough ballpark for 256-bit curve: 64 octet uncompressed point vs. 32 =
octet compressed point; curve check uncompressed point roughly <0.2% cos=
t scalar multiply vs. ~10% cost scalar multiply (based on figures I have se=
en floating around on the cfrg mailing list).}

>

> Your suggested "security concern" seems to be that implement=
ers will somehow not perform the curve check (why?) and that, by using poin=
t compression, you simply enforce it indirectly (since recomputing the unco=
mpressed point from the compressed one includes checking whether the x-valu=
e is indeed the x-coordinate of a possible curve point). For implementers t=
hat *do* perform the curve check and do care more about performance than ab=
out the 32-octet communication savings, this would present a disadvantage. =



Ask Bouncycastle, Apple, and Go why they don't do this c=
heck. (Bouncycastle fixed it). The fact is implementations are exploitable =
as a result of taking shortcuts not revealed in ordinary testing.


Furthermore, x coordinate only is adequate for ECDH and was =
suggested in the original ECC paper.


>

> The only case where the latter does not incur such a large performance=
 hit seems to be in cases where scalar multiplication does not use the y-co=
ordinate at all (since then one does not care about y' and simply sees =
whether alpha is a quadratic residue). This does however restrict implement=
ation freedom.


Brier - Joyce is also slower then table based fixed window m=
ethods. Furthermore,=C2=A0 not all curves in TLS are twist secure.

>

> If one were to be concerned about implementation attacks, why not have=
 people compute a compressed point R':=3D(x,y') from a received unc=
ompressed point R:=3D(x,y) {this simply requires taking y':=3Dy (mod 2)=
, i.e., determining the parity of y} and then do as you suggested.


They could validate the received point instead. Why decompre=
ss when you don't have to?

>

> Using uncompressed points gives people two mechanisms for preventing i=
nvalid point attacks (via curve check or point decompression), at slightly =
higher communication cost (32 octets) that seems easy to accept in most TLS=
 applications. Allowing freedom to choose either format gives people choice=
, also on communication cost side, at trivial cost of having a single octet=
 indicator. 

>

> This leads us back to the representation formats we currently have.
>

> Best regards, Rene

>

> =3D=3D

>

> Yes, but uncompressed points are not a security concern in X509, but t=
hey are in ECDH. Furthermore, the cost of adding compression support is ver=
y small: it's a square root, a check, and potentially flipping the sign=
. The benefit is that invalid point attacks are much harder to carry out.
>

> On 10/22/2014 12:11 PM, Watson Ladd wrote:

>>

>> On Tue, Oct 21, 2014 at 8:11 AM, Michael StJohns <msj@nthpermutation.com> wrote:

>> > On 10/21/2014 10:52 AM, Eric Rescorla wrote:

>> >

>> > htt=
ps://github.com/tlswg/tls13-spec/issues/80

>> >

>> > Today we discussed the possibility of requiring support for c=
ompressed

>> > points

>> > in TLS 1.3 now that the IPR has expired.

>> >

>> > Specifically, I propose that for TLS 1.3, we:

>> >

>> > - Use only compressed points for the existing curves (and pre=
sumably

>> > whatever superior format is defined for the CFRG-recommended<=
br>
>> > curves, as appropriate).

>> >

>> > - Deprecate the Supported Point Formats extension for TLS 1.3=


>> >

>> >

>> > I'm pretty much opposed to the former and I guess by exte=
nsion the latter.

>> >

>> > There's a very large body of code that doesn't suppor=
t anything except type

>> > 0x04(uncompressed) X9.63 point encodings. If you want to add =
support for

>> > compressed points (or hybrid compressed), I don't think t=
hat's necessarily a

>> > bad idea, but not at the expense of removing support for unco=
mpressed

>> > points. If you wanted to remove the supported point format ex=
tension, I

>> > guess you could mandate support for both compressed and uncom=
pressed (and

>> > hybrid?).

>>

>> There is a large body of code that doesn't support TLS 1.3 as =
well.

>> >

>> > As a second item, I would estimate the chance we're going=
 to see compressed

>> > points in X509 certificates as a regular thing prior to about=
 10 years from

>> > now as very small, meaning that any general transition to EC =
based suites is

>> > going to require uncompressed point support.

>>

>> Yes, but uncompressed points are not a security concern in X509, b=
ut they are in ECDH. Furthermore, the cost of adding compression support is=
 very small: it's a square root, a check, and potentially flipping the =
sign. The benefit is that invalid point attacks are much harder to carry ou=
t.

>>

>> >

>> > Lastly, while the base IPR for point compression seems to be =
no longer of

>> > concern, I've still been told to avoid it for a few more =
years due to

>> > implementation patents related to compression. I'm not su=
re how worrisome

>> > that is, but its one of the reasons that binary curves aren&#=
39;t in broader use

>> > still.

>> >

>> > Just my $.02

>> >

>> > Mike

>> >

>> >

>> >

>> > For RFC 4492-bis, we might also consider requiring support fo=
r compressed

>> > points as well as uncompressed (already required) but this se=
ems like a

>> > separable issue, since it's mostly in service of optimiza=
tion rather than

>> > simplicity.

>> >

>> > What do people think?

>> > -Ekr

>> >

>> >

>> >

>> >

>> >

>> >

>> >

>> > _______________________________________________

>> > TLS mailing list

>> > TLS@ietf.org

>> > https:/=
/www.ietf.org/mailman/listinfo/tls

>> >

>> >

>> >

>> > _______________________________________________

>> > TLS mailing list

>> > TLS@ietf.org

>> > https:/=
/www.ietf.org/mailman/listinfo/tls

>> >

>>

>> --

>> "Those who would give up Essential Liberty to purchase a litt=
le Temporary Safety deserve neither Liberty nor Safety."

>> -- Benjamin Franklin

>>

>>

>>

>> _______________________________________________

>> TLS mailing list

>> TLS@ietf.org

>> https://www.=
ietf.org/mailman/listinfo/tls

>

>

>

> -- 

> email: rstruik.ext@gmail.com<=
/a> | Skype: rstruik

> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


--001a113321ae4396d00506077432--


From nobody Wed Oct 22 11:59:40 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F4A1ACFEB for ; Wed, 22 Oct 2014 11:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chlbXzFSazMX for ; Wed, 22 Oct 2014 11:59:34 -0700 (PDT)
Received: from mx202.easyname.com (mx202.easyname.com [212.232.28.123]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD6F1ACFEF for ; Wed, 22 Oct 2014 11:59:32 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xh183-0002Va-SH; Wed, 22 Oct 2014 20:59:30 +0200
Message-ID: <5447FE79.1050008@fussenegger.info>
Date: Wed, 22 Oct 2014 20:59:05 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nico Williams , "tls@ietf.org" 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org> 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020301050103070208060201"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eK-Y2mCv0dWa_W_NogBj1DYCzqU
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 18:59:36 -0000

This is a cryptographically signed message in MIME format.

--------------ms020301050103070208060201
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

On 10/22/2014 8:46 PM, Nico Williams wrote:
> On Mon, Oct 20, 2014 at 6:58 PM, Viktor Dukhovni  wrote:
>> On Mon, Oct 20, 2014 at 11:39:31PM +0200, Manuel P?gouri?-Gonnard wrot=
e:
>>>> The RFC should clarify that the negotiated cipher **MUST** be honore=
d
>>>> when encrypting the state that will be sent to the client. [1]
>> I am having trouble parsing the original suggestion above.
> Even parsed as the context implies, there's problems: a) the client
> can't verify that the ticket is encrypted in any given cipher, b) why
> on Earth should the server let the client choose what cipher is used
> for the Ticket?, c) given (a), what is to be gained by any party from
> the server using the client's desired cipher for encrypting the
> ticket?
[erm] That was not the original suggestion and 'negotiated cipher'=20
doesn't imply that the cipher was chosen by the client. It's merely a=20
fact that the server and the client have to negotiate a cipher before=20
they can establish an encrypted communication channel. It doesn't matter =

how they do that, but at some point they'll negotiate a cipher (or no=20
connection is established at all).

If the two of us agree upon using AES-256, wouldn't you be a little bit=20
disappointed if I send you an encrypted ticket of that stuff we agreed=20
upon to encrypt with AES-256 that is actually encrypted with AES-128?=20
You wouldn't notice, because you can't read the ticket and trust that I=20
honor our negotiations (after all, we were communication through a=20
AES-256 secured channel which we negotiated, didn't we).

Well=97fact is=97today web servers are doing exactly that with tickets an=
d=20
that's why some people have problems with them and that's what I was=20
referring to in my very first mail (quoted above).

>>> While I'm sympathetic with the goal, I'm afraid that will complicate
>>> implementations more than necessary. How about requiring to use a key=
 length at
>>> least a high as the highest supported ciphersuite instead?
> This is just as silly.  The server should choose what cipher to use, fu=
ll stop.
It does.

>> Does it mean (as I think you're saying) that session tickets MUST
>> be encrypted with the session's negotiated ciphersuite?  That seems
>> rather unmanageable.  A single sufficiently strong key is likely
>> far more realistic.
> Yes.
I already agreed upon the single key solution.


>> With keys for clusters of servers rotated by code external to the
>> TLS library, asking for a key for every algorith/size is impractical.
> One would derive keys for all ciphers from a single cluster master
> key.  Nonetheless, it's just plain silly to let the client/connection
> dictate how to encrypt the ticket -- that's the server's prerogative.
>
> Nico
> --
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
That's impractical for administrators that aren't running dedicated key=20
generation servers within their own data center.

Actually everything Viktor Dukhovni said is perfectly correct and Nico I =

think you may have misunderstood a few things here.

Regards
Richard


--------------ms020301050103070208060201
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjIxODU5MDVaMCMGCSqGSIb3DQEJBDEWBBQdzErJCmCWeE/xTqTr4QibVBBrTTBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEAaJySgfu5pGdJyjptvamyWMzBFPUD
noKsCwj1+dY7Dl5HUSF3wA/2TQ/Ssr33qqUH4hgE7fNNzI7u5poBnM1vGU+RwJcw5H2fK4O3
G7eWvUAE2sSBxo7fJGp1EXMSSUEaNaI1jnBMht7Cm0eEIRGN9CsVSHDNVabD6xLnDFNPdEyS
Rw5H9M57FVTPrXSDcf4v/f0YCV/ZSUl1WF27wGCWRP7VCUBxGEmqiL+RrAIkdvtDdKMOFCbc
YUPemoIrfjq/9TnbJSobqo6/x1KMpt5KoYE5QFnrXRXwS6GgpCbt0n+F13KrHONOdkx0sROi
jLlwYwFJ5mbyE4EC9vbF8O3VqwAAAAAAAA==
--------------ms020301050103070208060201--


From nobody Wed Oct 22 12:10:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564931ACFFC for ; Wed, 22 Oct 2014 12:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP0lbWn3ohcT for ; Wed, 22 Oct 2014 12:10:21 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4891AD006 for ; Wed, 22 Oct 2014 12:09:39 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CD3E52AB04A; Wed, 22 Oct 2014 19:09:37 +0000 (UTC)
Date: Wed, 22 Oct 2014 19:09:37 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141022190937.GI19158@mournblade.imrryr.org>
References:  <5447FA87.40007@fussenegger.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5447FA87.40007@fussenegger.info>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6tk4sc-1DGPf1RS2H19YX2EkYIk
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 19:10:33 -0000

On Wed, Oct 22, 2014 at 08:42:15PM +0200, Richard Fussenegger wrote:

> Viktor Dukhovni already mentioned that
> OpenSSL is actually supporting different key strengths, but for instance
> nginx isn't exposing this setting to administrators.

For the record OpenSSL makes it possible for applications to use
some other block cipher than aes-128-cbc, but this is not as easy
as it sounds.  The application needs to register appropriate
callbacks and take over key life-cycle management.  So simply using
some other cipher-suite is not a trivial exercise, rather only once
one is already managing key rotation via the callbacks, making the
cipher configurable is trivial:

The code for this is roughly:

    #define TLS_TICKET_NAMELEN      16      /* RFC 5077 ticket key name length */
    #define TLS_TICKET_IVLEN        16      /* RFC 5077 ticket IV length */
    #define TLS_TICKET_KEYLEN       32      /* AES-256-CBC key size */
    #define TLS_TICKET_MACLEN       32      /* RFC 5077 HMAC key size */

    typedef struct TLS_TICKET_KEY {
	unsigned char name[TLS_TICKET_NAMELEN];
	unsigned char bits[TLS_TICKET_KEYLEN];
	unsigned char hmac[TLS_TICKET_MACLEN];
	time_t  tout;
    } TLS_TICKET_KEY;

    #define NOENGINE				((ENGINE *) 0)
    #define TLS_TKT_NOKEYS	-1		/* No keys for encryption */
    #define TLS_TKT_STALE	0		/* No matching keys for decryption */
    #define TLS_TKT_ACCEPT	1		/* Ticket decryptable and re-usable */
    #define TLS_TKT_REISSUE	2		/* Ticket decryptable, not re-usable */

    static int ticket_cb(SSL *con, unsigned char name[], unsigned char iv[],
			      EVP_CIPHER_CTX * ctx, HMAC_CTX * hctx, int create)
    {
	static const EVP_MD *sha256;
	static const EVP_CIPHER *ciph;
	TLS_TICKET_KEY *key;
	int     timeout = ((int) SSL_CTX_get_timeout(SSL_get_SSL_CTX(con))) / 2;

	if ((!sha256 && (sha256 = EVP_sha256()) == 0)
	    || (!ciph && (ciph = EVP_get_cipherbyname(var_tls_tkt_cipher)) == 0)
	    || (key = tls_mgr_key(create ? 0 : name, timeout)) == 0
	    || (create && RAND_bytes(iv, TLS_TICKET_IVLEN) <= 0))
	    return (create ? TLS_TKT_NOKEYS : TLS_TKT_STALE);

	HMAC_Init_ex(hctx, key->hmac, TLS_TICKET_MACLEN, sha256, NOENGINE);

	if (create) {
	    EVP_EncryptInit_ex(ctx, ciph, NOENGINE, key->bits, iv);
	    memcpy((char *) name, (char *) key->name, TLS_TICKET_NAMELEN);
	} else {
	    EVP_DecryptInit_ex(ctx, ciph, NOENGINE, key->bits, iv);
	}
	return (TLS_TKT_ACCEPT);
    }

Plus additional supporting functions to fetch encryption/decryption
keys, subject to appopriate key rotation policies, (in the above
case tls_mgr_key() whose implementation is rather application
specific).

Perhaps I'll donate a variant of this code to OpenSSL, and then we
can ask users to just provide algorithm name, and either a key
lifetime for automatic in memory keys or callbacks to access
externally managed keys.

-- 
	Viktor.


From nobody Wed Oct 22 12:20:31 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983991AD1BA for ; Wed, 22 Oct 2014 12:20:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3EiwFUwTr-A for ; Wed, 22 Oct 2014 12:20:07 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA1D1AD03D for ; Wed, 22 Oct 2014 12:20:06 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 19:20:04 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Wed, 22 Oct 2014 19:20:04 +0000
From: Andrei Popov 
To: Joseph Salowey , "mrex@sap.com" 
Thread-Topic: [TLS] Summary of discussion regarding spontaneuous authentication
Thread-Index: AQHP7fDMBbHKs/HZikCNW7QhrPmUL5w8OvCAgAAaHACAACXv0A==
Date: Wed, 22 Oct 2014 19:20:04 +0000
Message-ID: <4d4ef6ab70914023988340e2ca9f02d1@BL2PR03MB419.namprd03.prod.outlook.com>
References:  <20141022151819.44A791AF05@ld9781.wdf.sap.corp> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB418;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 037291602B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(3905003)(377454003)(199003)(189002)(24454002)(19609705001)(40100003)(15975445006)(87936001)(2656002)(85306004)(108616004)(92566001)(122556002)(85852003)(19580395003)(86362001)(19580405001)(15202345003)(76576001)(74316001)(19300405004)(106116001)(33646002)(19617315012)(105586002)(16236675004)(107046002)(99396003)(120916001)(106356001)(76482002)(21056001)(80022003)(95666004)(46102003)(99286002)(64706001)(86612001)(20776003)(4396001)(54356999)(31966008)(50986999)(97736003)(76176999)(101416001)(19625215002)(2501002)(24736002)(562404015); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_4d4ef6ab70914023988340e2ca9f02d1BL2PR03MB419namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RSZyOxdZyWU2ibLfUk_Qgb5zDs8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous	authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 19:20:16 -0000

--_000_4d4ef6ab70914023988340e2ca9f02d1BL2PR03MB419namprd03pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBoYXZlIHRoZSBzYW1lIGNvbmNlcm4gYXMgSm9lOiBub3QgYWxsIGFwcGxpY2F0aW9ucyBoYXZl
IGEgbWVjaGFuaXNtIGluIHBsYWNlIHRvIHJlcXVlc3QgVExTIGNsaWVudCBhdXRoOyBzdWNoIGFw
cHMgd291bGQgbm90IGJlIGFibGUgdG8gdXNlIFRMUzEuMy4gTm9yIGlzIGl0IGRlc2lyYWJsZSB0
byB1cGRhdGUgYWxsIHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbHMgdGhhdCB1c2UgVExTIGNsaWVu
dCBhdXRoLiBXZSBuZWVkIHRoaXMgbWVjaGFuaXNtIGluIHRoZSBUTFMgaGFuZHNoYWtlLCBhbmQg
cGVyaGFwcyB3ZSBjYW4gZG8gYmV0dGVyIHRoYW4gQ2VydGlmaWNhdGVSZXF1ZXN0OiBjZXJ0aWZp
Y2F0ZSB0eXBlIGFuZCB0cnVzdGVkIGlzc3VlcnMgbGlzdCBhcmUgbm90IHRoZSBvbmx5IHVzZWZ1
bCBjcmVkZW50aWFsIHNlbGVjdGlvbiBjcml0ZXJpYS4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0K
RnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb3Nl
cGggU2Fsb3dleQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDIyLCAyMDE0IDk6NTIgQU0NClRv
OiBtcmV4QHNhcC5jb20NCkNjOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBTdW1t
YXJ5IG9mIGRpc2N1c3Npb24gcmVnYXJkaW5nIHNwb250YW5ldW91cyBhdXRoZW50aWNhdGlvbg0K
DQoNCk9uIFdlZCwgT2N0IDIyLCAyMDE0IGF0IDg6MTggQU0sIE1hcnRpbiBSZXggPG1yZXhAc2Fw
LmNvbTxtYWlsdG86bXJleEBzYXAuY29tPj4gd3JvdGU6DQpNYXJ0aW4gVGhvbXNvbiB3cm90ZToN
Cj4NCj4gV2UgZGlzY3Vzc2VkIHRoZSByZW1vdmFsIG9mIHRoZSBDZXJ0aWZpY2F0ZVJlcXVlc3Qg
YW5kIHdlIHdpbGwgcGVybWl0DQo+IHRoZSBjbGllbnQgdG8gdW5pbGF0ZXJhbGx5IHNlbmQgYXV0
aGVudGljYXRpb24uDQo+DQo+IFRoZSB0aGVvcnkgaGVyZSBpcyB0aGF0IGNsaWVudHMgdGVuZCB0
byBrbm93IHdoZXRoZXIgdGhleSBuZWVkIHRvDQo+IGF1dGhlbnRpY2F0ZS4NCg0KVGhpcyBsb29r
cyBsaWtlIGEgYmFkIGlkZWEgdG8gbWUuDQpUaGUgYnkgZmFyIG1vc3QgaW1wb3J0YW50IGluZm9y
bWF0aW9uIGluIHRoZSBjdXJyZW50IENlcnRpZmljYXRlUmVxdWVzdA0KaGFuZHNoYWtlIG1lc3Nh
Z2UgaXMgdGhlICJjZXJ0aWZpY2F0aW9uX2F1dGhvcml0aWVzIiBmaWVsZCwgd2hpY2ggaW5kaWNh
dGVzDQpjZXJ0aWZpY2F0ZSBpc3N1ZXJzIHdoaWNoIHRoZSBzZXJ2ZXIgY29uc2lkZXJzIGFjY2Vw
dGFibGUuDQpJbiBTU0x2MyBhbmQgVExTdjEuMCB0aGUgY2VydGlmaWNhdGVfYXV0aG9yaXRpZXMg
ZmllbGQgd2FzIHJlcXVpcmVkDQp0byBiZSBub24tZW1wdHkgYW5kIG5vIChzZXJ2ZXIpIGJlaGF2
aW91ciB3YXMgZGVmaW5lZCBmb3IgdGhlIG1lYW5pbmcNCm9mIGFuIGVtcHR5IGNlcnRpZmljYXRp
b25fYXV0aG9yaXRpZXMgZmllbGQgaW4gQ2VydGlmaWNhdGVSZXF1ZXN0Lg0KDQpUaGUgVExTdjEu
MSBhbmQgVExTdjEuMiBzcGVjaWZpY2F0aW9uIGNvbnRhaW4gYSBkZWZlY3QgaW4gdGhhdCB0aGV5
DQptb2RpZmllZCB0aGUgUERVIGRlZmluaXRpb24gdG8gYWxsb3cgYW4gZW1wdHkgY2VydGlmaWNh
dGlvbl9hdXRob3JpdGllcw0KZmllbGQgaW4gQ2VydGlmaWNhdGVSZXF1ZXN0LCBidXQgZmFpbGVk
IHRvIGRlZmluZSAocmVxdWlyZSkgYSBzZXJ2ZXINCmJlaGF2aW91ciB3aGVuIHRoZSBzZXJ2ZXIg
ZG9lcyBub3Qgc2VuZCB0aGlzIGluZm9ybWF0aW9uLg0KV2l0aG91dCB0aGUgcmVxdWlyZW1lbnQs
IHRoYXQgdGhlIHNlcmVyIE1VU1QgTk9UIGFib3J0IHRoZSBUTFMgaGFuZHNoYWtlDQp3aGVuIHNl
bmRpbmcgYW4gZW1wdHkgY2VydGlmaWNhdGVfYXV0aG9yaXRpZXMgYW5kIHJlY2VpdmluZyBhIGNl
cnRpZmljYXRlDQp3aGljaCBpdCBkb2VzIG5vdCB0cnVzdCwgdGhlIHVzZSBvZiBhbiBlbXB0eSBj
ZXJ0aWZpY2F0ZV9hdXRob3JpdGllcw0KZmllbGQgZG9lcyBub3QgbWFrZSBzZW5zZS4NCg0KDQpX
aXRoIHJlY2VudCB2ZXJzaW9ucyBvZiBMeW5jLCBNaWNyb3NvZnQgc2VlbXMgdG8gYXV0b21hdGlj
YWxseSBjcmVhdGUgYQ0KTHluYy1zcGVjaWZpYyAiU1NMIGNsaWVudCBpZGVudGl0eSIgdGhhdCB3
b3JrcyBmb3Igbm90aGluZyBidXQgTHluYywgYnV0DQp3aWxsIHN1Y2Nlc3NmdWxseSBpbnRlcmZl
cmUgd2l0aCBTU0wgY2xpZW50IGNyZWRlbnRpYWxzIHNlbGVjdGlvbnMgd2hlbg0KYnJvd3NlcnMg
YXJlIHVzaW5nIGFuIFNTTCBjbGllbnQgaWRlbnRpdHkgZm9yIGFjY2Vzc2luZyByZWd1bGFyIFdl
YiBzaXRlcy4NCg0KVG8gbWFrZSBTU0wgY2xpZW50IGNlcnRpZmljYXRlIGF1dGhlbnRpY2F0aW9u
IHdvcmsgcmVhc29uYWJseQ0KYSBDZXJ0aWZpY2F0ZVJlcXVlc3QgdGhhdCBjb252ZXlzIGFjY2Vw
dGFibGUgY2VydGlmaWNhdGVfYXV0aG9yaXRpZXMNCmZvciB0aGUgc3BlY2lmaWMgaGFuZHNoYWtl
IGlzIGFic29sdXRlbHkgbmVjZXNzYXJ5Lg0KDQpBcHBsZSBTYWZhcmkgc2VlbXMgdG8gYmUgbm90
b3Jpb3VzbHkgYnJva2VuIHdoZW4gaXQgY29tZXMgdG8gU1NMIGNsaWVudA0KY2VydGlmaWNhdGUg
c2VsZWN0aW9uLCBiZWNhdXNlIGl0IGZhaWxzIHRvIHByb2Nlc3MgdGhlIGNlcnRpZmljYXRlX2F1
dGhvcml0aWVzDQpmaWVsZCBmcm9tIGEgQ2VydGlmaWNhdGVSZXF1ZXN0IGhhbmRzaGFrZSBtZXNz
YWdlIGFuZCByZW1vdmUgb2J2aW91c2x5DQp1bmFjY2VwdGFibGUgY2VydHMgZnJvbSB0aGUgbGlz
dCBvZiBjcmVkZW50aWFscyB0aGF0IHRoZSB1c2VyIGlzDQpwcmVzZW50ZWQgdG8gc2VsZWN0IGZy
b20uICAgSSd2ZSBoYWQgY3VzdG9tZXJzIHJlcG9ydCBjb25uZWN0aW9uDQpmYWlsdXJlcyB0byBv
dXIgQXBwU2VydmVycywgYW5kIGZyb20gdGhlIHNlcnZlci1zaWRlIGVycm9yIG1lc3NhZ2VzDQpJ
IGNvdWxkIHNlZSB0aGF0IHRoZSBjbGllbnQgd2FzIHRyeWluZyB0byBjb25uZWN0IHdpdGggc29t
ZSBhcHBsZWlkDQpjZXJ0aWZpY2F0ZSB0aGF0IG91ciBzZXJ2ZXIgZGlkbid0IHRydXN0IChhbmQg
Y2VydGFpbmx5IG5ldmVyIGFubm91bmNlZA0KaW4gdGhlIENlcnRpZmljYXRlUmVxdWVzdC5jZXJ0
aWZpY2F0ZV9hdXRob3JpdGllcyBmaWVsZC4NCg0KTWljcm9zb2Z0IGhhZCBhIHNpbWlsYXIgcHJv
YmxlbSBpbiBXaW5IVFRQIGluIDIwMDUNCmh0dHA6Ly9zdXBwb3J0Lm1pY3Jvc29mdC5jb20va2Iv
OTA5NDI1L2VuDQoNCkFmdGVyIFdpbkhUVFAgd2FzIGZpeGVkIHRvIHByb3ZpZGUgdGhlIG5lY2Vz
c2FyeSBpbmZvcm1hdGlvbg0KdG8gYXBwbGljYXRpb24gY2FsbGVycywgaXQgaXMgc3RpbGwgbmVj
ZXNzYXJ5IGZvciBhcHBsaWNhdGlvbiBjYWxsZXJzDQp0byBhY3R1YWxseSBfdXNlXyB0aGF0IGlu
Zm9ybWF0aW9uIHRvIHNlbGVjdCBvbmx5IGFjY2VwdGFibGUgY2VydGlmaWNhdGVzLA0KYW5kIHRo
YXQgc2VlbXMgdG8gdGFrZSB5ZWFycyB0byBoYXBwZW4uDQpUaGlzIGlzIHRoZSBmaXggZm9yIE9m
ZmljZS9XZWJEQVY6DQpodHRwOi8vc3VwcG9ydC5taWNyb3NvZnQuY29tL2tiLzI2NDc5NTQvZW4N
Cg0KQW5kIEFwcGxlIFNhZmFyaSA0IFdpbmRvd3MgYWxzbyBzdGlsbCBoYXMgdGhpcyBidWcgdG9k
YXkuDQoNCg0KV2l0aCB0aGUgY2VydGlmaWNhdGVfYXV0aG9yaXRpZXMgZmllbGQgaW4gdGhlIGN1
cnJlbnQgQ2VydGlmaWNhdGVSZXF1ZXN0DQpoYW5kc2hha2UgbWVzc2FnZSwgdGhlc2UgYXJlIG9u
bHkgKGZpeGFibGUpIGJ1Z3MuICBXaXRoIHRoZSByZW1vdmFsDQpvZiB0aGUgQ2VydGlmaWNhdGVS
ZXF1ZXN0IGhhbmRzaGFrZSBtZXNzYWdlLCB0aGlzIHByb2JsZW0gd291bGQgYmUNCnByb21vdGVk
IHRvIGEgVExTdjEuMyBwcm90b2NvbCBkZXNpZ24gZmxhdywgYW5kIGJlY29tZSB1bmZpeGFibGUu
DQoNCltKb2VdICBJJ20gYWxzbyBjb25jZXJuZWQgdGhhdCByZW1vdmluZyB0aGUgY2VydGlmaWNh
dGUgcmVxdWVzdCBpbiBmYXZvciBvZiBzb21lIGFwcGxpY2F0aW9uIGluZGljYXRpb24gd2lsbCBs
ZWF2ZSBiZWhpbmQgYXBwbGljYXRpb25zIHRoYXQgZG8gbm90IGN1cnJlbnRseSBoYXZlIGEgbWVj
aGFuaXNtIHRvIGNvbW11bmljYXRlIHRoaXMuICAgSWYgd2UgYXJlIGdvaW5nIHRvIHJlbW92ZSB0
aGUgY2VydGlmaWNhdGUgcmVxdWVzdCBJIHRoaW5rIHdlIHdpbGwgbmVlZCB0byBjb21tdW5pY2F0
ZSB0aGlzIGluZm9ybWF0aW9uIGluIHRoZSBoYW5kc2hha2UgaXRzZWxmIG9yIHBlcmhhcHMgaGF2
ZSBhICJyZWNvbm5lY3Rpb24gcmVxdWVzdCIuDQoNCg0KDQoNCi1NYXJ0aW4NCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QN
ClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby90bHMNCg0K

--_000_4d4ef6ab70914023988340e2ca9f02d1BL2PR03MB419namprd03pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46
MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT
ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk
ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K
PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+
PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp
bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSB0
aGUgc2FtZSBjb25jZXJuIGFzIEpvZTogbm90IGFsbCBhcHBsaWNhdGlvbnMgaGF2ZSBhIG1lY2hh
bmlzbSBpbiBwbGFjZSB0byByZXF1ZXN0IFRMUyBjbGllbnQgYXV0aDsgc3VjaCBhcHBzIHdvdWxk
IG5vdCBiZSBhYmxlIHRvIHVzZSBUTFMxLjMuIE5vciBpcw0KIGl0IGRlc2lyYWJsZSB0byB1cGRh
dGUgYWxsIHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbHMgdGhhdCB1c2UgVExTIGNsaWVudCBhdXRo
LiBXZSBuZWVkIHRoaXMgbWVjaGFuaXNtIGluIHRoZSBUTFMgaGFuZHNoYWtlLCBhbmQgcGVyaGFw
cyB3ZSBjYW4gZG8gYmV0dGVyIHRoYW4gQ2VydGlmaWNhdGVSZXF1ZXN0OiBjZXJ0aWZpY2F0ZSB0
eXBlIGFuZCB0cnVzdGVkIGlzc3VlcnMgbGlzdCBhcmUgbm90IHRoZSBvbmx5IHVzZWZ1bCBjcmVk
ZW50aWFsIHNlbGVjdGlvbg0KIGNyaXRlcmlhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRMUyBb
bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb3NlcGgg
U2Fsb3dleTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9jdG9iZXIgMjIsIDIwMTQgOTo1
MiBBTTxicj4NCjxiPlRvOjwvYj4gbXJleEBzYXAuY29tPGJyPg0KPGI+Q2M6PC9iPiB0bHNAaWV0
Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIFN1bW1hcnkgb2YgZGlzY3Vzc2lv
biByZWdhcmRpbmcgc3BvbnRhbmV1b3VzIGF1dGhlbnRpY2F0aW9uPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgT2N0IDIyLCAyMDE0IGF0IDg6MTggQU0sIE1h
cnRpbiBSZXggJmx0OzxhIGhyZWY9Im1haWx0bzptcmV4QHNhcC5jb20iIHRhcmdldD0iX2JsYW5r
Ij5tcmV4QHNhcC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk1hcnRp
biBUaG9tc29uIHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGRpc2N1c3NlZCB0aGUgcmVt
b3ZhbCBvZiB0aGUgQ2VydGlmaWNhdGVSZXF1ZXN0IGFuZCB3ZSB3aWxsIHBlcm1pdDxicj4NCiZn
dDsgdGhlIGNsaWVudCB0byB1bmlsYXRlcmFsbHkgc2VuZCBhdXRoZW50aWNhdGlvbi48YnI+DQom
Z3Q7PGJyPg0KJmd0OyBUaGUgdGhlb3J5IGhlcmUgaXMgdGhhdCBjbGllbnRzIHRlbmQgdG8ga25v
dyB3aGV0aGVyIHRoZXkgbmVlZCB0bzxicj4NCiZndDsgYXV0aGVudGljYXRlLjxicj4NCjxicj4N
ClRoaXMgbG9va3MgbGlrZSBhIGJhZCBpZGVhIHRvIG1lLjxicj4NClRoZSBieSBmYXIgbW9zdCBp
bXBvcnRhbnQgaW5mb3JtYXRpb24gaW4gdGhlIGN1cnJlbnQgQ2VydGlmaWNhdGVSZXF1ZXN0PGJy
Pg0KaGFuZHNoYWtlIG1lc3NhZ2UgaXMgdGhlICZxdW90O2NlcnRpZmljYXRpb25fYXV0aG9yaXRp
ZXMmcXVvdDsgZmllbGQsIHdoaWNoIGluZGljYXRlczxicj4NCmNlcnRpZmljYXRlIGlzc3VlcnMg
d2hpY2ggdGhlIHNlcnZlciBjb25zaWRlcnMgYWNjZXB0YWJsZS48YnI+DQpJbiBTU0x2MyBhbmQg
VExTdjEuMCB0aGUgY2VydGlmaWNhdGVfYXV0aG9yaXRpZXMgZmllbGQgd2FzIHJlcXVpcmVkPGJy
Pg0KdG8gYmUgbm9uLWVtcHR5IGFuZCBubyAoc2VydmVyKSBiZWhhdmlvdXIgd2FzIGRlZmluZWQg
Zm9yIHRoZSBtZWFuaW5nPGJyPg0Kb2YgYW4gZW1wdHkgY2VydGlmaWNhdGlvbl9hdXRob3JpdGll
cyBmaWVsZCBpbiBDZXJ0aWZpY2F0ZVJlcXVlc3QuPGJyPg0KPGJyPg0KVGhlIFRMU3YxLjEgYW5k
IFRMU3YxLjIgc3BlY2lmaWNhdGlvbiBjb250YWluIGEgZGVmZWN0IGluIHRoYXQgdGhleTxicj4N
Cm1vZGlmaWVkIHRoZSBQRFUgZGVmaW5pdGlvbiB0byBhbGxvdyBhbiBlbXB0eSBjZXJ0aWZpY2F0
aW9uX2F1dGhvcml0aWVzPGJyPg0KZmllbGQgaW4gQ2VydGlmaWNhdGVSZXF1ZXN0LCBidXQgZmFp
bGVkIHRvIGRlZmluZSAocmVxdWlyZSkgYSBzZXJ2ZXI8YnI+DQpiZWhhdmlvdXIgd2hlbiB0aGUg
c2VydmVyIGRvZXMgbm90IHNlbmQgdGhpcyBpbmZvcm1hdGlvbi48YnI+DQpXaXRob3V0IHRoZSBy
ZXF1aXJlbWVudCwgdGhhdCB0aGUgc2VyZXIgTVVTVCBOT1QgYWJvcnQgdGhlIFRMUyBoYW5kc2hh
a2U8YnI+DQp3aGVuIHNlbmRpbmcgYW4gZW1wdHkgY2VydGlmaWNhdGVfYXV0aG9yaXRpZXMgYW5k
IHJlY2VpdmluZyBhIGNlcnRpZmljYXRlPGJyPg0Kd2hpY2ggaXQgZG9lcyBub3QgdHJ1c3QsIHRo
ZSB1c2Ugb2YgYW4gZW1wdHkgY2VydGlmaWNhdGVfYXV0aG9yaXRpZXM8YnI+DQpmaWVsZCBkb2Vz
IG5vdCBtYWtlIHNlbnNlLjxicj4NCjxicj4NCjxicj4NCldpdGggcmVjZW50IHZlcnNpb25zIG9m
IEx5bmMsIE1pY3Jvc29mdCBzZWVtcyB0byBhdXRvbWF0aWNhbGx5IGNyZWF0ZSBhPGJyPg0KTHlu
Yy1zcGVjaWZpYyAmcXVvdDtTU0wgY2xpZW50IGlkZW50aXR5JnF1b3Q7IHRoYXQgd29ya3MgZm9y
IG5vdGhpbmcgYnV0IEx5bmMsIGJ1dDxicj4NCndpbGwgc3VjY2Vzc2Z1bGx5IGludGVyZmVyZSB3
aXRoIFNTTCBjbGllbnQgY3JlZGVudGlhbHMgc2VsZWN0aW9ucyB3aGVuPGJyPg0KYnJvd3NlcnMg
YXJlIHVzaW5nIGFuIFNTTCBjbGllbnQgaWRlbnRpdHkgZm9yIGFjY2Vzc2luZyByZWd1bGFyIFdl
YiBzaXRlcy48YnI+DQo8YnI+DQpUbyBtYWtlIFNTTCBjbGllbnQgY2VydGlmaWNhdGUgYXV0aGVu
dGljYXRpb24gd29yayByZWFzb25hYmx5PGJyPg0KYSBDZXJ0aWZpY2F0ZVJlcXVlc3QgdGhhdCBj
b252ZXlzIGFjY2VwdGFibGUgY2VydGlmaWNhdGVfYXV0aG9yaXRpZXM8YnI+DQpmb3IgdGhlIHNw
ZWNpZmljIGhhbmRzaGFrZSBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeS48YnI+DQo8YnI+DQpBcHBs
ZSBTYWZhcmkgc2VlbXMgdG8gYmUgbm90b3Jpb3VzbHkgYnJva2VuIHdoZW4gaXQgY29tZXMgdG8g
U1NMIGNsaWVudDxicj4NCmNlcnRpZmljYXRlIHNlbGVjdGlvbiwgYmVjYXVzZSBpdCBmYWlscyB0
byBwcm9jZXNzIHRoZSBjZXJ0aWZpY2F0ZV9hdXRob3JpdGllczxicj4NCmZpZWxkIGZyb20gYSBD
ZXJ0aWZpY2F0ZVJlcXVlc3QgaGFuZHNoYWtlIG1lc3NhZ2UgYW5kIHJlbW92ZSBvYnZpb3VzbHk8
YnI+DQp1bmFjY2VwdGFibGUgY2VydHMgZnJvbSB0aGUgbGlzdCBvZiBjcmVkZW50aWFscyB0aGF0
IHRoZSB1c2VyIGlzPGJyPg0KcHJlc2VudGVkIHRvIHNlbGVjdCBmcm9tLiZuYnNwOyAmbmJzcDtJ
J3ZlIGhhZCBjdXN0b21lcnMgcmVwb3J0IGNvbm5lY3Rpb248YnI+DQpmYWlsdXJlcyB0byBvdXIg
QXBwU2VydmVycywgYW5kIGZyb20gdGhlIHNlcnZlci1zaWRlIGVycm9yIG1lc3NhZ2VzPGJyPg0K
SSBjb3VsZCBzZWUgdGhhdCB0aGUgY2xpZW50IHdhcyB0cnlpbmcgdG8gY29ubmVjdCB3aXRoIHNv
bWUgYXBwbGVpZDxicj4NCmNlcnRpZmljYXRlIHRoYXQgb3VyIHNlcnZlciBkaWRuJ3QgdHJ1c3Qg
KGFuZCBjZXJ0YWlubHkgbmV2ZXIgYW5ub3VuY2VkPGJyPg0KaW4gdGhlIENlcnRpZmljYXRlUmVx
dWVzdC5jZXJ0aWZpY2F0ZV9hdXRob3JpdGllcyBmaWVsZC48YnI+DQo8YnI+DQpNaWNyb3NvZnQg
aGFkIGEgc2ltaWxhciBwcm9ibGVtIGluIFdpbkhUVFAgaW4gMjAwNTxicj4NCjxhIGhyZWY9Imh0
dHA6Ly9zdXBwb3J0Lm1pY3Jvc29mdC5jb20va2IvOTA5NDI1L2VuIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cDovL3N1cHBvcnQubWljcm9zb2Z0LmNvbS9rYi85MDk0MjUvZW48L2E+PGJyPg0KPGJyPg0K
QWZ0ZXIgV2luSFRUUCB3YXMgZml4ZWQgdG8gcHJvdmlkZSB0aGUgbmVjZXNzYXJ5IGluZm9ybWF0
aW9uPGJyPg0KdG8gYXBwbGljYXRpb24gY2FsbGVycywgaXQgaXMgc3RpbGwgbmVjZXNzYXJ5IGZv
ciBhcHBsaWNhdGlvbiBjYWxsZXJzPGJyPg0KdG8gYWN0dWFsbHkgX3VzZV8gdGhhdCBpbmZvcm1h
dGlvbiB0byBzZWxlY3Qgb25seSBhY2NlcHRhYmxlIGNlcnRpZmljYXRlcyw8YnI+DQphbmQgdGhh
dCBzZWVtcyB0byB0YWtlIHllYXJzIHRvIGhhcHBlbi48YnI+DQpUaGlzIGlzIHRoZSBmaXggZm9y
IE9mZmljZS9XZWJEQVY6PGJyPg0KPGEgaHJlZj0iaHR0cDovL3N1cHBvcnQubWljcm9zb2Z0LmNv
bS9rYi8yNjQ3OTU0L2VuIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3N1cHBvcnQubWljcm9zb2Z0
LmNvbS9rYi8yNjQ3OTU0L2VuPC9hPjxicj4NCjxicj4NCkFuZCBBcHBsZSBTYWZhcmkgNCBXaW5k
b3dzIGFsc28gc3RpbGwgaGFzIHRoaXMgYnVnIHRvZGF5Ljxicj4NCjxicj4NCjxicj4NCldpdGgg
dGhlIGNlcnRpZmljYXRlX2F1dGhvcml0aWVzIGZpZWxkIGluIHRoZSBjdXJyZW50IENlcnRpZmlj
YXRlUmVxdWVzdDxicj4NCmhhbmRzaGFrZSBtZXNzYWdlLCB0aGVzZSBhcmUgb25seSAoZml4YWJs
ZSkgYnVncy4mbmJzcDsgV2l0aCB0aGUgcmVtb3ZhbDxicj4NCm9mIHRoZSBDZXJ0aWZpY2F0ZVJl
cXVlc3QgaGFuZHNoYWtlIG1lc3NhZ2UsIHRoaXMgcHJvYmxlbSB3b3VsZCBiZTxicj4NCnByb21v
dGVkIHRvIGEgVExTdjEuMyBwcm90b2NvbCBkZXNpZ24gZmxhdywgYW5kIGJlY29tZSB1bmZpeGFi
bGUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5bSm9lXSAmbmJzcDtJJ20gYWxzbyBjb25jZXJuZWQgdGhhdCByZW1vdmluZyB0aGUg
Y2VydGlmaWNhdGUgcmVxdWVzdCBpbiBmYXZvciBvZiBzb21lIGFwcGxpY2F0aW9uIGluZGljYXRp
b24gd2lsbCBsZWF2ZSBiZWhpbmQgYXBwbGljYXRpb25zIHRoYXQgZG8gbm90IGN1cnJlbnRseSBo
YXZlIGEgbWVjaGFuaXNtIHRvIGNvbW11bmljYXRlIHRoaXMuICZuYnNwOyBJZiB3ZSBhcmUgZ29p
bmcgdG8gcmVtb3ZlIHRoZSBjZXJ0aWZpY2F0ZQ0KIHJlcXVlc3QgSSB0aGluayB3ZSB3aWxsIG5l
ZWQgdG8gY29tbXVuaWNhdGUgdGhpcyBpbmZvcm1hdGlvbiBpbiB0aGUgaGFuZHNoYWtlIGl0c2Vs
ZiBvciBwZXJoYXBzIGhhdmUgYSAmcXVvdDtyZWNvbm5lY3Rpb24gcmVxdWVzdCZxdW90Oy4gJm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KLU1hcnRpbjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy
Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpU
TFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGll
dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vdGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_4d4ef6ab70914023988340e2ca9f02d1BL2PR03MB419namprd03pro_--


From nobody Wed Oct 22 12:24:52 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4DD1AD371 for ; Wed, 22 Oct 2014 12:24:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJr3w2KTVQLI for ; Wed, 22 Oct 2014 12:24:37 -0700 (PDT)
Received: from mx207.easyname.com (mx207.easyname.com [212.232.25.163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AEB11AD021 for ; Wed, 22 Oct 2014 12:24:37 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xh1WL-0001dp-DD for tls@ietf.org; Wed, 22 Oct 2014 21:24:35 +0200
Message-ID: <5448045C.3010108@fussenegger.info>
Date: Wed, 22 Oct 2014 21:24:12 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References:  <5447FA87.40007@fussenegger.info> <20141022190937.GI19158@mournblade.imrryr.org>
In-Reply-To: <20141022190937.GI19158@mournblade.imrryr.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020001000909050900080908"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TjE7LJjqrKlwvihxco5itr8gLgg
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 19:24:45 -0000

This is a cryptographically signed message in MIME format.

--------------ms020001000909050900080908
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

On 10/22/2014 9:09 PM, Viktor Dukhovni wrote:
> On Wed, Oct 22, 2014 at 08:42:15PM +0200, Richard Fussenegger wrote:
>
>> Viktor Dukhovni already mentioned that
>> OpenSSL is actually supporting different key strengths, but for instan=
ce
>> nginx isn't exposing this setting to administrators.
> For the record OpenSSL makes it possible for applications to use
> some other block cipher than aes-128-cbc, but this is not as easy
> as it sounds.  The application needs to register appropriate
> callbacks and take over key life-cycle management.  So simply using
> some other cipher-suite is not a trivial exercise, rather only once
> one is already managing key rotation via the callbacks, making the
> cipher configurable is trivial:
>
> The code for this is roughly:
>
>      #define TLS_TICKET_NAMELEN      16      /* RFC 5077 ticket key nam=
e length */
>      #define TLS_TICKET_IVLEN        16      /* RFC 5077 ticket IV leng=
th */
>      #define TLS_TICKET_KEYLEN       32      /* AES-256-CBC key size */=

>      #define TLS_TICKET_MACLEN       32      /* RFC 5077 HMAC key size =
*/
>
>      typedef struct TLS_TICKET_KEY {
> 	unsigned char name[TLS_TICKET_NAMELEN];
> 	unsigned char bits[TLS_TICKET_KEYLEN];
> 	unsigned char hmac[TLS_TICKET_MACLEN];
> 	time_t  tout;
>      } TLS_TICKET_KEY;
>
>      #define NOENGINE				((ENGINE *) 0)
>      #define TLS_TKT_NOKEYS	-1		/* No keys for encryption */
>      #define TLS_TKT_STALE	0		/* No matching keys for decryption */
>      #define TLS_TKT_ACCEPT	1		/* Ticket decryptable and re-usable */
>      #define TLS_TKT_REISSUE	2		/* Ticket decryptable, not re-usable */=

>
>      static int ticket_cb(SSL *con, unsigned char name[], unsigned char=
 iv[],
> 			      EVP_CIPHER_CTX * ctx, HMAC_CTX * hctx, int create)
>      {
> 	static const EVP_MD *sha256;
> 	static const EVP_CIPHER *ciph;
> 	TLS_TICKET_KEY *key;
> 	int     timeout =3D ((int) SSL_CTX_get_timeout(SSL_get_SSL_CTX(con))) =
/ 2;
>
> 	if ((!sha256 && (sha256 =3D EVP_sha256()) =3D=3D 0)
> 	    || (!ciph && (ciph =3D EVP_get_cipherbyname(var_tls_tkt_cipher)) =3D=
=3D 0)
> 	    || (key =3D tls_mgr_key(create ? 0 : name, timeout)) =3D=3D 0
> 	    || (create && RAND_bytes(iv, TLS_TICKET_IVLEN) <=3D 0))
> 	    return (create ? TLS_TKT_NOKEYS : TLS_TKT_STALE);
>
> 	HMAC_Init_ex(hctx, key->hmac, TLS_TICKET_MACLEN, sha256, NOENGINE);
>
> 	if (create) {
> 	    EVP_EncryptInit_ex(ctx, ciph, NOENGINE, key->bits, iv);
> 	    memcpy((char *) name, (char *) key->name, TLS_TICKET_NAMELEN);
> 	} else {
> 	    EVP_DecryptInit_ex(ctx, ciph, NOENGINE, key->bits, iv);
> 	}
> 	return (TLS_TKT_ACCEPT);
>      }
>
> Plus additional supporting functions to fetch encryption/decryption
> keys, subject to appopriate key rotation policies, (in the above
> case tls_mgr_key() whose implementation is rather application
> specific).
>
> Perhaps I'll donate a variant of this code to OpenSSL, and then we
> can ask users to just provide algorithm name, and either a key
> lifetime for automatic in memory keys or callbacks to access
> externally managed keys.
>
That would be great and exactly what the world needs. It's also the=20
reason for my proposed changes that should be made during merge of=20
RFC5077, so that OpenSSL will finally implement proper configurable=20
rotation and configurable ticket ciphers. Applications like nginx=20
wouldn't have to start implementing cryptographic stuff (which is a=20
dangerous game), rather simply exposing the configuration options of=20
OpenSSL which handles everything internally.

A nice to have above this would be some warning that is emitted if=20
ciphers are configured that are actually stronger than the key used for=20
the tickets. But that's already implementation specific stuff and has=20
nothing to do with the RFC.

Richard


--------------ms020001000909050900080908
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjIxOTI0MTJaMCMGCSqGSIb3DQEJBDEWBBTh2jY+krmyTLWoV9r1WfMpoVJi2zBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEALPGbFzmKXExw4woCWjsz2qH7Ehym
zNU0WTMWvZkhSEsb+k1o1I26itbGm3Hqgjy4zGXGnkNYfOKNKX5uw9S3Nt2hQYmp8JwIoCNC
IPWGXVMN5WX7Y87LMQy0mkVvY2jLnGEMG4cI/g11SZz5j94Cc9gFD+u+l+5V4B+EKKN2rwdP
W7cBMGExNJljc1G8SjyH3wZRqphPwM7ceNooImzN8IgOx5QWzYHaCNnpqEisTtsTJrS7Pg9N
NAG+JRESsacLMLVRoAbAtpoSZje1J530OsDXvZP83ExTWrlAiP5N55fwKVQLLn8bqQWDrSD0
QdaDUsY1bIdbdaPnYxwmJOQrwwAAAAAAAA==
--------------ms020001000909050900080908--


From nobody Wed Oct 22 12:39:31 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354D71AD39E for ; Wed, 22 Oct 2014 12:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAdHoLtlCPj9 for ; Wed, 22 Oct 2014 12:39:27 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0139.outbound.protection.outlook.com [207.46.100.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4768A1ACF11 for ; Wed, 22 Oct 2014 12:39:27 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 19:39:25 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Wed, 22 Oct 2014 19:39:25 +0000
From: Andrei Popov 
To: Martin Thomson , Eric Rescorla 
Thread-Topic: [TLS] Should we require compressed points
Thread-Index: AQHP7T7GIZmtj79MzkKyCxpOg7rXUJw8aWnQgAAHbYCAAAXWAIAAC2vA
Date: Wed, 22 Oct 2014 19:39:25 +0000
Message-ID: <9be8381163a04dd9b0ff1e7945b18eb2@BL2PR03MB419.namprd03.prod.outlook.com>
References:  <1799fe49d54b4d43acc26778b9265c8a@BL2PR03MB419.namprd03.prod.outlook.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB418;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 037291602B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(13464003)(24454002)(377454003)(95666004)(99286002)(46102003)(120916001)(99396003)(21056001)(80022003)(106356001)(76482002)(54356999)(31966008)(4396001)(50986999)(101416001)(97736003)(76176999)(86612001)(64706001)(20776003)(108616004)(92566001)(85306004)(19580395003)(86362001)(19580405001)(93886004)(85852003)(122556002)(40100003)(2656002)(87936001)(106116001)(33646002)(107046002)(105586002)(74316001)(76576001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Fxj7BGKwGqUHJX6_jhK0FwsbTH0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 19:39:29 -0000

SSdtIG5vdCBjb252aW5jZWQgdGhhdCBhIHJlcXVpcmVtZW50IHRvIHN1cHBvcnQgbXVsdGlwbGUg
cG9pbnQgY29tcHJlc3Npb24gYWxnb3JpdGhtcyBoZWxwcyBlbGltaW5hdGUgY29tcGxleGl0eTop
Lg0KDQpQb2ludCBjb21wcmVzc2lvbiBkb2VzIGhlbHAgc2F2ZSBhIGJpdCBvZiBzcGFjZSwgc28g
dGhhdCB3ZSBjYW4gY2FycnkgbW9yZSBvZiB0aG9zZSBsb3ZlbHkgaHVtYW4tcmVhZGFibGUgQUxQ
TiBJRHMuIEkgYWdyZWUgdGhhdCBwb2ludCBjb21wcmVzc2lvbiBtYXkgYmUgYSB2YWx1YWJsZSBm
ZWF0dXJlLg0KDQpXaGlsZSBJIHdvdWxkIHByZWZlciB0byBrZWVwIHVuY29tcHJlc3NlZCBwb2lu
dHMsIHRoaXMgd291bGQgbm90IGJlIGEgZGVhbC1icmVha2VyIGZvciBtZS4gTG9zaW5nIHN1cHBv
cnQgZm9yIHJlbmVnb3RpYXRpb24gY29uY2VybnMgbWUgbXVjaCBtb3JlLg0KDQpDaGVlcnMsDQoN
CkFuZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21z
b24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBP
Y3RvYmVyIDIyLCAyMDE0IDExOjQ3IEFNDQpUbzogRXJpYyBSZXNjb3JsYQ0KQ2M6IEFuZHJlaSBQ
b3BvdjsgdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gU2hvdWxkIHdlIHJlcXVpcmUg
Y29tcHJlc3NlZCBwb2ludHMNCg0KT24gMjIgT2N0b2JlciAyMDE0IDExOjI2LCBFcmljIFJlc2Nv
cmxhIDxla3JAcnRmbS5jb20+IHdyb3RlOg0KPj4gV2hhdCBhcmUgdGhlIHJlYXNvbnMgZm9yIGdl
dHRpbmcgcmlkIG9mIHVuY29tcHJlc3NlZCBwb2ludHM/DQo+DQo+DQo+IFJlYWxseSB3aGF0IEkg
d2FudCBpcyB0byBnZXQgcmlkIG9mIHBvaW50IG5lZ290aWF0aW9uLCBiZWNhdXNlIGl0J3MgDQo+
IHlldCBhbm90aGVyIHBvaW50IG9mIGNvbXBsZXhpdHkgYW5kIGl0J3Mgbm90IHVuaXZlcnNhbGx5
IGltcGxlbWVudGVkIA0KPiBhbnl3YXkuIEdpdmVuIHRoYXQgcGVvcGxlIHNlZW0gdG8gdGhpbmsg
dGhhdCBjb21wcmVzc2VkIHBvaW50cyBhcmUgDQo+IGJldHRlciwgSSBmaWd1cmVkIHRoYXQgd2Fz
IHRoZSB3YXkgdG8gZ28uIElmIHBlb3BsZSBwcmVmZXIgdG8ganVzdCANCj4gcmVxdWlyZSB1bmNv
bXByZXNzZWQgcG9pbnRzIChhdCBsZWFzdCBmb3IgdGhlIGV4aXN0aW5nIFg5LjYzIGN1cnZlcykg
SSANCj4gY291bGQgY2VydGFpbmx5IGxpdmUgd2l0aCB0aGF0Lg0KDQpZZXAsIGFuZCBJJ2xsIG5v
dGUgdGhhdCAzMiBvY3RldHMgaXNuJ3QgYSB0cml2aWFsIGFtb3VudCBvZiBzcGFjZSBpbiBhIGhh
bmRzaGFrZS4gIFdlJ3JlIHBhcnRpY3VsYXJseSBzcGFjZSBjb25zdHJhaW5lZCBoZXJlLiAgSWYg
dGhhdCdzIDMyIG9jdGV0cyBtb3JlIG9mIGFwcGxpY2F0aW9uIGRhdGEgSSdkIGhhdmUgYXZhaWxh
YmxlLCBJIHN1c3BlY3QgdGhhdCBhbm90aGVyIGNvbXByZXNzZWQgSFRUUC8yIHJlcXVlc3QgLSBv
ciBhIGdvb2QgcHJvcG9ydGlvbiBvZiBvbmUgLSBjb3VsZCBmaXQgaW4gdGhhdCBzcGFjZSAoZm9y
IGEgMCBSVFQgbW9kZSBpbiBwYXJ0aWN1bGFyKS4NCg==


From nobody Wed Oct 22 12:43:15 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8081AD3E4 for ; Wed, 22 Oct 2014 12:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.266
X-Spam-Level: 
X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFwAIT4VDH4X for ; Wed, 22 Oct 2014 12:43:10 -0700 (PDT)
Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 19CB51AD3CC for ; Wed, 22 Oct 2014 12:43:05 -0700 (PDT)
Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id D128B2AC06E; Wed, 22 Oct 2014 12:43:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=5mTJOs8ilpmAu+ vKeazTeCKww2M=; b=h4kvhSCzIrsZ0jJIZuEH9tMRDbGN5eoJeQjbfY54mHIZKg qbsR7Fk3yvCnmchj9u6btbfbhJ936P1aNGgJ+ljgprKAj9HiADR8zCaPHSpzYvAC CX0MXPe41eTzpFJQVAir/Z5ef6nGPe891wGLPLEFWXTYG7IOrV49Fn5NOwTd4=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPA id 8D4B22AC059; Wed, 22 Oct 2014 12:43:04 -0700 (PDT)
Date: Wed, 22 Oct 2014 14:43:03 -0500
From: Nico Williams 
To: Richard Fussenegger 
Message-ID: <20141022194302.GA6170@localhost>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org>  <5447FE79.1050008@fussenegger.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5447FE79.1050008@fussenegger.info>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SFcXm8LUjmv7DBMIcAJqMHLUavM
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 19:43:13 -0000

On Wed, Oct 22, 2014 at 08:59:05PM +0200, Richard Fussenegger wrote:
> On 10/22/2014 8:46 PM, Nico Williams wrote:
> >Even parsed as the context implies, there's problems: a) the client
> >can't verify that the ticket is encrypted in any given cipher, b) why
> >on Earth should the server let the client choose what cipher is used
> >for the Ticket?, c) given (a), what is to be gained by any party from
> >the server using the client's desired cipher for encrypting the
> >ticket?
>
> [erm] That was not the original suggestion and 'negotiated cipher'
> doesn't imply that the cipher was chosen by the client. It's merely
> [...]

It does imply that the client at least constrained the choice of cipher.

This is unnecessary complexity.  I thought we were all for simplifying.

> If the two of us agree upon using AES-256, wouldn't you be a little
> bit disappointed if I send you an encrypted ticket of that stuff we
> agreed upon to encrypt with AES-256 that is actually encrypted with
> AES-128? You wouldn't notice, because you can't read the ticket and

No: because I couldn't prove that it isn't AES-256, because the server
couldn't prove that it is, because the only way to do so would be for
the server to give me its ticket encryption key, which would defeat the
purpose.

Well, I tell a lie: the server could give the client the ticket
encryption key for expired tickets issued to the same client.  But this
means having a per-client set of keys, which means having some client ID
to derive keys from, probably a public key that the client can
demonstrate it has possession of the corresponding private key, and so
on and so forth -- all much, much too complex.

The client already has to trust the server for all sorts of things.
Having to trust it to handle ticket encryption appropriately is not much
more to ask, especially since any reasonable choice on the server's part
is such a large optimization/win over not having session resumption that
it's worth the risks of the complexity of session resumption (because
the alternative is risking less deployment).

> [...]
> 
> >>>While I'm sympathetic with the goal, I'm afraid that will complicate
> >>>implementations more than necessary. How about requiring to use a key length at
> >>>least a high as the highest supported ciphersuite instead?
> >This is just as silly.  The server should choose what cipher to use, full stop.
> It does.
> 
> >>Does it mean (as I think you're saying) that session tickets MUST
> >>be encrypted with the session's negotiated ciphersuite?  That seems
> >>rather unmanageable.  A single sufficiently strong key is likely
> >>far more realistic.
> >Yes.
> I already agreed upon the single key solution.

So you want the server to say "fine, I'm using the XYZ cipher that you
wanted", and now what changes?  The server can't prove that it did / the
client can't prove that the server didn't.  What did we gain, besides
more [in this case worth-less] complexity?

One answer: someone could audit the server's compliance with this.  But
who?!  Not the client.  Some authority perhaps, which then opens a can
of worms.  And then what do we gain?  What about clients who end up
getting weaker ticket encryption ciphers than the server's preference?

Nico
-- 


From nobody Wed Oct 22 12:47:00 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2A91AD3F4 for ; Wed, 22 Oct 2014 12:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx7vkeOsj9-V for ; Wed, 22 Oct 2014 12:46:47 -0700 (PDT)
Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id ABB5D1AD3EF for ; Wed, 22 Oct 2014 12:46:47 -0700 (PDT)
Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 5224B9406D for ; Wed, 22 Oct 2014 12:46:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=lAEY9+S3QHsnPQ/VPUl4hG9JJXA =; b=Fv4xMXt9wDvdsjX6rAf8YfU8fqMX/y7TEcsWa476S6wvjz1fJUPL8NDeqvr xjsba8q3C47jhOlIvID3Ertc/TVF77Eip4WINlDYFrfc++jkjpN4k39dmaaPgVFe 5occXjCu99CLSfDlaVyy0OtElVTB2U9gVHaUOlzkjPpBg8Uc=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 2302894065 for ; Wed, 22 Oct 2014 12:46:47 -0700 (PDT)
Date: Wed, 22 Oct 2014 14:46:46 -0500
From: Nico Williams 
To: tls@ietf.org
Message-ID: <20141022194644.GB6170@localhost>
References:  <5447FA87.40007@fussenegger.info> <20141022190937.GI19158@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20141022190937.GI19158@mournblade.imrryr.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/u75YaE2x8WM207r677xSD4tx04g
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 19:46:48 -0000

On Wed, Oct 22, 2014 at 07:09:37PM +0000, Viktor Dukhovni wrote:
> On Wed, Oct 22, 2014 at 08:42:15PM +0200, Richard Fussenegger wrote:
> > Viktor Dukhovni already mentioned that
> > OpenSSL is actually supporting different key strengths, but for instance
> > nginx isn't exposing this setting to administrators.
> 
> For the record OpenSSL makes it possible for applications to use
> some other block cipher than aes-128-cbc, but this is not as easy
> as it sounds.  The application needs to register appropriate
> callbacks and take over key life-cycle management.  So simply using
> some other cipher-suite is not a trivial exercise, rather only once
> one is already managing key rotation via the callbacks, making the
> cipher configurable is trivial:

Polite words fail me.  (Not a reference to your code, Viktor.)

This sort of thing should be expressible in a much simpler way: as a
one-liner or with local configuration/policy.

Nico
-- 


From nobody Wed Oct 22 13:24:42 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3F61A03A0 for ; Wed, 22 Oct 2014 13:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7td9Uwmfz5xy for ; Wed, 22 Oct 2014 13:24:38 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7581A0263 for ; Wed, 22 Oct 2014 13:24:38 -0700 (PDT)
Received: by mail-ig0-f171.google.com with SMTP id l13so85789iga.4 for ; Wed, 22 Oct 2014 13:24:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=bUMUzd7hrdnT9FbNAWnFbkO2XL5AcunZenskkc/ZKVU=; b=SSKwmonJfe1Rno5TWNlgD64kseV1uG54DUahKDvS2ZSH/7eA1FxQs05Qjs6kMQ1ioO A+rKfQI3N/acgmbw6jXBY3DLQNA9Hyz/7DxHc37J5E7AP+K38kkhAaNVFWOIK/Bx/AwM rxN89UeUC1ngTLNR/pwHI9/ewz2r/mrAU+MbChTHl9ewhYZVgizKrPXPDLTvVmj98OKa WJ28M5mV3s4Nrkgg4UAFaryTCYTbYPv7bnV4/4gETX1kf8RvyeMXx4GLwtLIqICxMh3N Eh6lbnZ3/Ws3swyNNL0XjcfXbc/Lm6PRYMJxStbS7cdmyPG79KpSw0L/6ouI/Yu6Geg4 zmkg==
X-Received: by 10.50.79.232 with SMTP id m8mr37247920igx.11.1414009477104; Wed, 22 Oct 2014 13:24:37 -0700 (PDT)
Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id y64sm8000647iod.0.2014.10.22.13.24.36 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Oct 2014 13:24:36 -0700 (PDT)
Message-ID: <54481274.2020008@gmail.com>
Date: Wed, 22 Oct 2014 16:24:20 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Watson Ladd 
References: 	<544677AE.4000005@nthpermutation.com>		<5447E307.3010104@gmail.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070107000000020604040400"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G-J_0j0AdM3gXogeixJVNwLacIo
Cc: tls@ietf.org
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 20:24:41 -0000

This is a multi-part message in MIME format.
--------------070107000000020604040400
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Watson:

Your argument seems to be biased towards x-coordinate only calculations. 
There may very well be good reasons for implementations using the 
y-coordinate of a received point in their implementation as well, in 
which case forcing those to incur a ~10% of scalar multiply performance 
hit by offering only compressed objects seems to be somewhat brutal.

Best regards, Rene

On 10/22/2014 2:52 PM, Watson Ladd wrote:
>
>
> On Oct 22, 2014 10:02 AM, "Rene Struik"  > wrote:
> >
> > Hi Watson:
> >
> > I do not understand your statement below: the cost of 
> "decompressing" points may be not that insignificant and, depending on 
> application, one might rather send uncompressed points instead.
> >
> > For simplicity, let us assume a short-Weierstrass curve E with 
> defining equation y^2 = x^3 + a x + b (mod p). (A similar argument 
> holds for other curves, of course.)
> >
> > If one receives an uncompressed alleged point R:=(x,y), one has to 
> check whether this is indeed on the curve E. This comes roughly at 
> cost 2S+1M (where S=squaring; M=multiply).
> > If one receives a compressed point R':=(x,y') and requires the 
> corresponding uncompressed point R, one has to compute a solution y to 
> the equation y^2=alpha, where alpha:=x^3+ax+b (mod p) and (if there is 
> a solution) pick y or p-y, depending on the binary value y'. This 
> comes at roughly cost 1S + 1M+1SQRT (where SQRT=square root).
> >
> > The trade-off here is that point compression slightly saves on 
> communication bandwidth, whereas it does increase computational cost 
> of scalar multiplies.
> > {Rough ballpark for 256-bit curve: 64 octet uncompressed point vs. 
> 32 octet compressed point; curve check uncompressed point roughly 
> <0.2% cost scalar multiply vs. ~10% cost scalar multiply (based on 
> figures I have seen floating around on the cfrg mailing list).}
> >
> > Your suggested "security concern" seems to be that implementers will 
> somehow not perform the curve check (why?) and that, by using point 
> compression, you simply enforce it indirectly (since recomputing the 
> uncompressed point from the compressed one includes checking whether 
> the x-value is indeed the x-coordinate of a possible curve point). For 
> implementers that *do* perform the curve check and do care more about 
> performance than about the 32-octet communication savings, this would 
> present a disadvantage.
>
> Ask Bouncycastle, Apple, and Go why they don't do this check. 
> (Bouncycastle fixed it). The fact is implementations are exploitable 
> as a result of taking shortcuts not revealed in ordinary testing.
>
> Furthermore, x coordinate only is adequate for ECDH and was suggested 
> in the original ECC paper.
>
> >
> > The only case where the latter does not incur such a large 
> performance hit seems to be in cases where scalar multiplication does 
> not use the y-coordinate at all (since then one does not care about y' 
> and simply sees whether alpha is a quadratic residue). This does 
> however restrict implementation freedom.
>
> Brier - Joyce is also slower then table based fixed window methods. 
> Furthermore,  not all curves in TLS are twist secure.
> >
> > If one were to be concerned about implementation attacks, why not 
> have people compute a compressed point R':=(x,y') from a received 
> uncompressed point R:=(x,y) {this simply requires taking y':=y (mod 
> 2), i.e., determining the parity of y} and then do as you suggested.
>
> They could validate the received point instead. Why decompress when 
> you don't have to?
> >
> > Using uncompressed points gives people two mechanisms for preventing 
> invalid point attacks (via curve check or point decompression), at 
> slightly higher communication cost (32 octets) that seems easy to 
> accept in most TLS applications. Allowing freedom to choose either 
> format gives people choice, also on communication cost side, at 
> trivial cost of having a single octet indicator.
> >
> > This leads us back to the representation formats we currently have.
> >
> > Best regards, Rene
> >
> > ==
> >
> > Yes, but uncompressed points are not a security concern in X509, but 
> they are in ECDH. Furthermore, the cost of adding compression support 
> is very small: it's a square root, a check, and potentially flipping 
> the sign. The benefit is that invalid point attacks are much harder to 
> carry out.
> >
> > On 10/22/2014 12:11 PM, Watson Ladd wrote:
> >>
> >> On Tue, Oct 21, 2014 at 8:11 AM, Michael StJohns 
> > wrote:
> >> > On 10/21/2014 10:52 AM, Eric Rescorla wrote:
> >> >
> >> > https://github.com/tlswg/tls13-spec/issues/80
> >> >
> >> > Today we discussed the possibility of requiring support for 
> compressed
> >> > points
> >> > in TLS 1.3 now that the IPR has expired.
> >> >
> >> > Specifically, I propose that for TLS 1.3, we:
> >> >
> >> > - Use only compressed points for the existing curves (and presumably
> >> > whatever superior format is defined for the CFRG-recommended
> >> > curves, as appropriate).
> >> >
> >> > - Deprecate the Supported Point Formats extension for TLS 1.3
> >> >
> >> >
> >> > I'm pretty much opposed to the former and I guess by extension 
> the latter.
> >> >
> >> > There's a very large body of code that doesn't support anything 
> except type
> >> > 0x04(uncompressed) X9.63 point encodings. If you want to add 
> support for
> >> > compressed points (or hybrid compressed), I don't think that's 
> necessarily a
> >> > bad idea, but not at the expense of removing support for uncompressed
> >> > points. If you wanted to remove the supported point format 
> extension, I
> >> > guess you could mandate support for both compressed and 
> uncompressed (and
> >> > hybrid?).
> >>
> >> There is a large body of code that doesn't support TLS 1.3 as well.
> >> >
> >> > As a second item, I would estimate the chance we're going to see 
> compressed
> >> > points in X509 certificates as a regular thing prior to about 10 
> years from
> >> > now as very small, meaning that any general transition to EC 
> based suites is
> >> > going to require uncompressed point support.
> >>
> >> Yes, but uncompressed points are not a security concern in X509, 
> but they are in ECDH. Furthermore, the cost of adding compression 
> support is very small: it's a square root, a check, and potentially 
> flipping the sign. The benefit is that invalid point attacks are much 
> harder to carry out.
> >>
> >> >
> >> > Lastly, while the base IPR for point compression seems to be no 
> longer of
> >> > concern, I've still been told to avoid it for a few more years due to
> >> > implementation patents related to compression. I'm not sure how 
> worrisome
> >> > that is, but its one of the reasons that binary curves aren't in 
> broader use
> >> > still.
> >> >
> >> > Just my $.02
> >> >
> >> > Mike
> >> >
> >> >
> >> >
> >> > For RFC 4492-bis, we might also consider requiring support for 
> compressed
> >> > points as well as uncompressed (already required) but this seems 
> like a
> >> > separable issue, since it's mostly in service of optimization 
> rather than
> >> > simplicity.
> >> >
> >> > What do people think?
> >> > -Ekr
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > TLS mailing list
> >> > TLS@ietf.org 
> >> > https://www.ietf.org/mailman/listinfo/tls
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > TLS mailing list
> >> > TLS@ietf.org 
> >> > https://www.ietf.org/mailman/listinfo/tls
> >> >
> >>
> >> --
> >> "Those who would give up Essential Liberty to purchase a little 
> Temporary Safety deserve neither Liberty nor Safety."
> >> -- Benjamin Franklin
> >>
> >>
> >>
> >> _______________________________________________
> >> TLS mailing list
> >> TLS@ietf.org 
> >> https://www.ietf.org/mailman/listinfo/tls
> >
> >
> >
> > --
> > email: rstruik.ext@gmail.com  | Skype: 
> rstruik
> > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


--------------070107000000020604040400
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Watson:

      

      Your argument seems to be biased towards x-coordinate only
      calculations. There may very well be good reasons for
      implementations using the y-coordinate of a received point in
      their implementation as well, in which case forcing those to incur
      a ~10% of scalar multiply performance hit by offering only
      compressed objects seems to be somewhat brutal.

      

      Best regards, Rene

      

      On 10/22/2014 2:52 PM, Watson Ladd wrote:

    

    

      


        On Oct 22, 2014 10:02 AM, "Rene Struik" <rstruik.ext@gmail.com>
        wrote:

        >

        > Hi Watson:

        >

        > I do not understand your statement below: the cost of
        "decompressing" points may be not that insignificant and,
        depending on application, one might rather send uncompressed
        points instead.

        >

        > For simplicity, let us assume a short-Weierstrass curve E
        with defining equation y^2 = x^3 + a x + b (mod p). (A similar
        argument holds for other curves, of course.)

        >

        > If one receives an uncompressed alleged point R:=(x,y), one
        has to check whether this is indeed on the curve E. This comes
        roughly at cost 2S+1M (where S=squaring; M=multiply).

        > If one receives a compressed point R':=(x,y') and requires
        the corresponding uncompressed point R, one has to compute a
        solution y to the equation y^2=alpha, where alpha:=x^3+ax+b (mod
        p) and (if there is a solution) pick y or p-y, depending on the
        binary value y'. This comes at roughly cost 1S + 1M+1SQRT (where
        SQRT=square root).

        >

        > The trade-off here is that point compression slightly saves
        on communication bandwidth, whereas it does increase
        computational cost of scalar multiplies.

        > {Rough ballpark for 256-bit curve: 64 octet uncompressed
        point vs. 32 octet compressed point; curve check uncompressed
        point roughly <0.2% cost scalar multiply vs. ~10% cost scalar
        multiply (based on figures I have seen floating around on the
        cfrg mailing list).}

        >

        > Your suggested "security concern" seems to be that
        implementers will somehow not perform the curve check (why?) and
        that, by using point compression, you simply enforce it
        indirectly (since recomputing the uncompressed point from the
        compressed one includes checking whether the x-value is indeed
        the x-coordinate of a possible curve point). For implementers
        that *do* perform the curve check and do care more about
        performance than about the 32-octet communication savings, this
        would present a disadvantage. 

      
Ask Bouncycastle, Apple, and Go why they don't do
        this check. (Bouncycastle fixed it). The fact is implementations
        are exploitable as a result of taking shortcuts not revealed in
        ordinary testing.

      
Furthermore, x coordinate only is adequate for ECDH
        and was suggested in the original ECC paper.

      
>

        > The only case where the latter does not incur such a large
        performance hit seems to be in cases where scalar multiplication
        does not use the y-coordinate at all (since then one does not
        care about y' and simply sees whether alpha is a quadratic
        residue). This does however restrict implementation freedom.

      
Brier - Joyce is also slower then table based fixed
        window methods. Furthermore,  not all curves in TLS are twist
        secure.

        >

        > If one were to be concerned about implementation attacks,
        why not have people compute a compressed point R':=(x,y') from a
        received uncompressed point R:=(x,y) {this simply requires
        taking y':=y (mod 2), i.e., determining the parity of y} and
        then do as you suggested.

      
They could validate the received point instead. Why
        decompress when you don't have to?

        >

        > Using uncompressed points gives people two mechanisms for
        preventing invalid point attacks (via curve check or point
        decompression), at slightly higher communication cost (32
        octets) that seems easy to accept in most TLS applications.
        Allowing freedom to choose either format gives people choice,
        also on communication cost side, at trivial cost of having a
        single octet indicator. 

        >

        > This leads us back to the representation formats we
        currently have.

        >

        > Best regards, Rene

        >

        > ==

        >

        > Yes, but uncompressed points are not a security concern in
        X509, but they are in ECDH. Furthermore, the cost of adding
        compression support is very small: it's a square root, a check,
        and potentially flipping the sign. The benefit is that invalid
        point attacks are much harder to carry out.

        >

        > On 10/22/2014 12:11 PM, Watson Ladd wrote:

        >>

        >> On Tue, Oct 21, 2014 at 8:11 AM, Michael StJohns <msj@nthpermutation.com>
        wrote:

        >> > On 10/21/2014 10:52 AM, Eric Rescorla wrote:

        >> >

        >> > https://github.com/tlswg/tls13-spec/issues/80

        >> >

        >> > Today we discussed the possibility of requiring
        support for compressed

        >> > points

        >> > in TLS 1.3 now that the IPR has expired.

        >> >

        >> > Specifically, I propose that for TLS 1.3, we:

        >> >

        >> > - Use only compressed points for the existing
        curves (and presumably

        >> > whatever superior format is defined for the
        CFRG-recommended

        >> > curves, as appropriate).

        >> >

        >> > - Deprecate the Supported Point Formats extension
        for TLS 1.3

        >> >

        >> >

        >> > I'm pretty much opposed to the former and I guess
        by extension the latter.

        >> >

        >> > There's a very large body of code that doesn't
        support anything except type

        >> > 0x04(uncompressed) X9.63 point encodings. If you
        want to add support for

        >> > compressed points (or hybrid compressed), I don't
        think that's necessarily a

        >> > bad idea, but not at the expense of removing
        support for uncompressed

        >> > points. If you wanted to remove the supported
        point format extension, I

        >> > guess you could mandate support for both
        compressed and uncompressed (and

        >> > hybrid?).

        >>

        >> There is a large body of code that doesn't support TLS
        1.3 as well.

        >> >

        >> > As a second item, I would estimate the chance
        we're going to see compressed

        >> > points in X509 certificates as a regular thing
        prior to about 10 years from

        >> > now as very small, meaning that any general
        transition to EC based suites is

        >> > going to require uncompressed point support.

        >>

        >> Yes, but uncompressed points are not a security concern
        in X509, but they are in ECDH. Furthermore, the cost of adding
        compression support is very small: it's a square root, a check,
        and potentially flipping the sign. The benefit is that invalid
        point attacks are much harder to carry out.

        >>

        >> >

        >> > Lastly, while the base IPR for point compression
        seems to be no longer of

        >> > concern, I've still been told to avoid it for a
        few more years due to

        >> > implementation patents related to compression. I'm
        not sure how worrisome

        >> > that is, but its one of the reasons that binary
        curves aren't in broader use

        >> > still.

        >> >

        >> > Just my $.02

        >> >

        >> > Mike

        >> >

        >> >

        >> >

        >> > For RFC 4492-bis, we might also consider requiring
        support for compressed

        >> > points as well as uncompressed (already required)
        but this seems like a

        >> > separable issue, since it's mostly in service of
        optimization rather than

        >> > simplicity.

        >> >

        >> > What do people think?

        >> > -Ekr

        >> >

        >> >

        >> >

        >> >

        >> >

        >> >

        >> >

        >> > _______________________________________________

        >> > TLS mailing list

        >> > TLS@ietf.org

        >> > https://www.ietf.org/mailman/listinfo/tls

        >> >

        >> >

        >> >

        >> > _______________________________________________

        >> > TLS mailing list

        >> > TLS@ietf.org

        >> > https://www.ietf.org/mailman/listinfo/tls

        >> >

        >>

        >> --

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

        >> -- Benjamin Franklin

        >>

        >>

        >>

        >> _______________________________________________

        >> TLS mailing list

        >> TLS@ietf.org

        >> https://www.ietf.org/mailman/listinfo/tls

        >

        >

        >

        > -- 

        > email: rstruik.ext@gmail.com
        | Skype: rstruik

        > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

    

    

    

    
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

  


--------------070107000000020604040400--


From nobody Wed Oct 22 13:28:25 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECEA1A1A04 for ; Wed, 22 Oct 2014 13:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BkZcuOb4Rok for ; Wed, 22 Oct 2014 13:28:21 -0700 (PDT)
Received: from mx204.easyname.com (mx204.easyname.com [212.232.28.125]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCB71A0264 for ; Wed, 22 Oct 2014 13:28:21 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xh2W1-0000b4-F2; Wed, 22 Oct 2014 22:28:19 +0200
Message-ID: <5448134B.8090700@fussenegger.info>
Date: Wed, 22 Oct 2014 22:27:55 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nico Williams 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org>  <5447FE79.1050008@fussenegger.info> <20141022194302.GA6170@localhost>
In-Reply-To: <20141022194302.GA6170@localhost>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070906090104030803020301"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_IAZNFUS9blOA-Yk_lelrJDEMoU
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 20:28:24 -0000

This is a cryptographically signed message in MIME format.

--------------ms070906090104030803020301
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

This isn't getting anywhere here, I'll try again but only once.

On 10/22/2014 9:43 PM, Nico Williams wrote:
> On Wed, Oct 22, 2014 at 08:59:05PM +0200, Richard Fussenegger wrote:
>> [erm] That was not the original suggestion and 'negotiated cipher'
>> doesn't imply that the cipher was chosen by the client. It's merely
>> [...]
> It does imply that the client at least constrained the choice of cipher=
=2E
>
> This is unnecessary complexity.  I thought we were all for simplifying.=


Negotiation -> TLS Handshake [1] -> ssl_prefer_server_ciphers=3Don [2]

The client will always create constraints because clients aren't=20
supporting only the strongest ciphers and protocols. That's the reason=20
why people configure more than one cipher and try to rescue SSL 3.0 from =

the POODLE.

> No: because I couldn't prove that it isn't AES-256, because the server
> couldn't prove that it is, because the only way to do so would be for
> the server to give me its ticket encryption key, which would defeat the=

> purpose.
>
> Well, I tell a lie: the server could give the client the ticket
> encryption key for expired tickets issued to the same client.  But this=

> means having a per-client set of keys, which means having some client I=
D
> to derive keys from, probably a public key that the client can
> demonstrate it has possession of the corresponding private key, and so
> on and so forth -- all much, much too complex.
>
> The client already has to trust the server for all sorts of things.
> Having to trust it to handle ticket encryption appropriately is not muc=
h
> more to ask, especially since any reasonable choice on the server's par=
t
> is such a large optimization/win over not having session resumption tha=
t
> it's worth the risks of the complexity of session resumption (because
> the alternative is risking less deployment).

Uh =85 nope =85

> So you want the server to say "fine, I'm using the XYZ cipher that you
> wanted", and now what changes?  The server can't prove that it did / th=
e
> client can't prove that the server didn't.  What did we gain, besides
> more [in this case worth-less] complexity?

Uh =85 nope =85

> One answer: someone could audit the server's compliance with this.  But=

> who?!  Not the client.  Some authority perhaps, which then opens a can
> of worms.  And then what do we gain?  What about clients who end up
> getting weaker ticket encryption ciphers than the server's preference?
>
> Nico

Telling people to use appropriate keys during all involved steps is=20
exactly what I propose and absolutely nothing of what you are alleging=20
me of.

 > Key strength **MUST** be at least of equal strength for ticket/token=20
encryption of the strongest supported cipher. Thus not downgrading any=20
of the available ciphers that can be used for communication. [3]

I'm getting the uncomfortable feeling that all I've written so far was=20
in Klingon =85

Regards
Richard

[1]=20
http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#TLS_HANDSHA=
KE=20
"Negotiating a secure TLS tunnel is a complicated process, [=85]"
[2]=20
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_prefer_server_=
ciphers
[3] The RFC shouldn't use the word 'negotiated' because it apparently=20
isn't understood correctly.


--------------ms070906090104030803020301
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjIyMDI3NTVaMCMGCSqGSIb3DQEJBDEWBBTvj45T+o/ZAwIy4LqJc1kx8nK3SzBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEAzoLHvqO04LLEQTE/VauSxec6a2f/
dGguKyiTM4YdN0J9NpIFJX4Er/4MXzr5OhoIrOV+iwpL06o8hNJynPRqQO3W7jICiBnnQPuv
OfR7y0yTFqraZkNjWxToD2Ww+Hu9sr/+oFcNMD257oRs3jv9vK0r9xTlztlC8rOPXCQ/Fp69
WusWzH3o8AKOcqeJL7T0SB7uY95KOpCpgL+Zn29SwFb0oX4TWBKAeRKg9aYp5J7jGwRPzz+s
H8Pv88pYPK9sySLT9Pdpa7UxAcyGpSlxnqZjDuRm/efMF3tXCa+VfZ8DdshjlTsPbiz5+gep
ruzwPiSssWZ8Y6xxglpP6srXdwAAAAAAAA==
--------------ms070906090104030803020301--


From nobody Wed Oct 22 13:32:40 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFDF1A1AF1 for ; Wed, 22 Oct 2014 13:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzNINbi3-rCT for ; Wed, 22 Oct 2014 13:32:38 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5888B1A1ADC for ; Wed, 22 Oct 2014 13:32:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=y/ao4IciSt7zCZpVMglosyhD4+1q9+lVH4yu6fzeFrE=;  b=cAKYmCZ2rtlExrdx9zw/mPI1NkmHPG8u5b5dLEXWfOg0oycfoSTV4DjnVOZKRR2XpaTlTYBvG2pc1pZk+IgfZC7xfm1inV2chegVtlL15gSb+7lOkdTg5NBkSD5XLD6YAomuktfjwsjQcqlz/A63HcO2DWWQerRxbQbglckL9GM=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xh2a6-0007i0-44; Wed, 22 Oct 2014 22:32:30 +0200
Message-ID: <54481461.8060006@polarssl.org>
Date: Wed, 22 Oct 2014 22:32:33 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Salz, Rich" ,  Martin Thomson , Ilari Liusvaara 
References:   <20141022125359.GA18704@LK-Perkele-VII>  <20141022132623.GA19894@LK-Perkele-VII>  <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4F98@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4F98@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EV5aB2E8wbGLr1CfjbtobOcmv1Q
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 20:32:39 -0000

On 22/10/2014 17:59, Salz, Rich wrote:
>> I tend to think that we need a more general mechanism for indicating
>> support for certificate types and signature algorithms.  Maybe we could
>> unconditionally include those in the early handshake instead.
> 
> Yes.  In two years when MSFT and Google start deprecating SHA-2 for Keccak,
> it'd be nice to know which cert chain to send.  Or when I don't know whether
> to send an RSA or ECDSA certificate next year.
> 
But you're on the server side, aren't you? There are indeed many reasons (RSA vs
ECDSA, SHA-x vs SHA-y) why a server wants to have many valid certs and pick one
based on what the client supports.

I'm not sure I can imagine so many plausible scenarios where the *client* has
many certs bound to the same identity and would need to pick one based on what
the server supports. Most of the time, the client cert will have been issued by
the same entity that runs the server, anyway.

Manuel.


From nobody Wed Oct 22 13:33:42 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944F71A1AA0 for ; Wed, 22 Oct 2014 13:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFaePJ812wxk for ; Wed, 22 Oct 2014 13:33:39 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396551A03A0 for ; Wed, 22 Oct 2014 13:33:39 -0700 (PDT)
Received: by mail-ig0-f170.google.com with SMTP id hn18so1630978igb.3 for ; Wed, 22 Oct 2014 13:33:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=gNY5+SONDsPx4hBXq1LkxDtUw6kxMUHUjj+d7YFq8Bg=; b=NWe3LEQQAZ0eFEwTpp/fQWx9aV/Q05XU7ogTrEFRZt5uPGalhksER0B6Ruj+wzwm/U KuFB2N9y/rBHFjPs4mTQUUdMc0k9NVuN9plbVmsHWD5WjCpYvi2HlyLijLNnPNSx3ci+ Qm96EHuRcz0zlsCxRjGbvoRQlnjRIR+a8Nz1N8EH0gmNbQB3c065yNU9KY2Utf2KTSUM EFbAewh0UKb7gqrA470CgmFxXAB/WLNa6afaWkFRBLsExx0+awLlj28o/fYIIgWiyD7G PNHhQlO2q9WGuYeerMSIpP2OY6/IlngbXLkm2W5yz/Yg5aFskiM0rx0BGjM/7qSKDKBz SVyA==
MIME-Version: 1.0
X-Received: by 10.107.28.203 with SMTP id c194mr482176ioc.29.1414010018542; Wed, 22 Oct 2014 13:33:38 -0700 (PDT)
Received: by 10.107.3.87 with HTTP; Wed, 22 Oct 2014 13:33:38 -0700 (PDT)
In-Reply-To: <1799fe49d54b4d43acc26778b9265c8a@BL2PR03MB419.namprd03.prod.outlook.com>
References:  <1799fe49d54b4d43acc26778b9265c8a@BL2PR03MB419.namprd03.prod.outlook.com>
Date: Wed, 22 Oct 2014 16:33:38 -0400
Message-ID: 
From: Jeffrey Walton 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PMhX17f2FZzP90x0UXaPJt4d5N0
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 20:33:40 -0000

> -          The =E2=80=9CIPR has expired=E2=80=9D statement will require l=
egal validation
> before an implementer can bake point compression into products;
Possible related: http://cr.yp.to/patents/us/6141420.html. The 420
patent expired in July 2014.

On Wed, Oct 22, 2014 at 2:15 PM, Andrei Popov
 wrote:
> A few considerations:
>
> -          The =E2=80=9CIPR has expired=E2=80=9D statement will require l=
egal validation
> before an implementer can bake point compression into products;
>
> -          Fewer bytes on the wire/more CPU is a good tradeoff in some
> scenarios, but probably not in every scenario;
>
> -          Requiring support for point compression imposes additional (ev=
en
> if relatively minor, in the scale of things) cost for TLS1.3 implementers=
.
>
>
> What are the reasons for getting rid of uncompressed points?
>
>
> Cheers,
>
>
> Andrei


From nobody Wed Oct 22 15:01:25 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFF61ACE56 for ; Wed, 22 Oct 2014 15:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM4Qx8aE7I2j for ; Wed, 22 Oct 2014 15:01:18 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46E01ACCEE for ; Wed, 22 Oct 2014 15:01:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414015277; x=1445551277; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=WDqSKzyUJjRFpPkBnVsTglwtrCYWBnGCbMNrKmd+mbg=; b=mUZcyyj6svtBP+04MujLSWLZubfCkpt6AnL922EUNW45YVdIC4XYUM2H 3SnB2OxcAKfjy5MS8CbXNfsQrDzAXMPGyRDwsBBwvi6C9vJIkDFj1Mwhr FXmUWZSqz1SOukOrh69qPBhqp4FdqoUsuJR2LjiIwj8aBYkRj3GLT27mq A=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="285107679"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 23 Oct 2014 11:01:15 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 11:01:15 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Should we require compressed points
Thread-Index: Ac/uQ7LIrWXOCG8DT5CgttEybxetlw==
Date: Wed, 22 Oct 2014 22:01:14 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IWFYnqGr6PInWQlH626KV-7AI5w
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 22:01:22 -0000

Eric Rescorla  writes:=0A=
=0A=
>Given that people seem to think that compressed points are better, I figur=
ed=0A=
>that was the way to go. If people prefer to just require uncompressed poin=
ts=0A=
>(at least for the existing X9.63 curves) I could certainly live with that.=
=0A=
=0A=
Uncompressed points have been a MUST in TLS since ECC was introduced, and a=
re=0A=
also a MUST everywhere else.  So adding compressed points as a MUST as well=
=0A=
won't get rid of uncompressed points in any way, it'll just add more option=
s=0A=
that need to be supported.=0A=
=0A=
Peter.=


From nobody Wed Oct 22 15:05:33 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782151AD0C7 for ; Wed, 22 Oct 2014 15:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtuOKEFdDGx9 for ; Wed, 22 Oct 2014 15:05:24 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966191AD0B5 for ; Wed, 22 Oct 2014 15:05:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414015523; x=1445551523; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=0Dvh6xMgxgHj18x7ImH5I+6g/nvJup+xoGghxtxNHKY=; b=GEqSMbZl6GD6XWXPjMJVP/8akNNDOP2akNCEIVgJ2j0APcRVghgVCwKx TIJSccoAAniHZbZ64p1LejDteB8wCiM0+m+igtjyKYGgArelUmlNrAO+s 1dEJr/ScWPKu/jOk0exhdgSK4cAkGmRjYu8BzCvg892gAh6PDsYQQwVIm k=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="285111580"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 23 Oct 2014 11:05:22 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 11:05:22 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Should we require compressed points
Thread-Index: Ac/uREUpVp3/DFDqSFuEkHItOnnd1g==
Date: Wed, 22 Oct 2014 22:05:20 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D6118@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/X3S66ahK-tMTL9tiuYsDb1iuR3Y
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 22:05:30 -0000

Watson Ladd  writes:=0A=
=0A=
>Ask Bouncycastle, Apple, and Go why they don't do this check. (Bouncycastl=
e=0A=
>fixed it). The fact is implementations are exploitable as a result of taki=
ng=0A=
>shortcuts not revealed in ordinary testing.=0A=
=0A=
Do you have more information on this?=0A=
=0A=
In any case though, the determined programmer can goto fail no matter what =
you=0A=
do, so adding a requirement for point compression will just mean they'll sc=
rew=0A=
things up elsewhere.  In addition since they have to keep supporting=0A=
uncompressed points all it'll do is add more things for them to mess up.=0A=
=0A=
Peter.=


From nobody Wed Oct 22 15:12:19 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D061A70E2 for ; Wed, 22 Oct 2014 15:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level: 
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyIN4nwk_2xf for ; Wed, 22 Oct 2014 15:12:10 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9E21A7031 for ; Wed, 22 Oct 2014 15:12:10 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A3FA34759E; Wed, 22 Oct 2014 22:12:09 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 97EA64759D; Wed, 22 Oct 2014 22:12:09 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 92D70202E; Wed, 22 Oct 2014 22:12:09 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 22 Oct 2014 18:12:09 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 22 Oct 2014 18:12:08 -0400
From: "Salz, Rich" 
To: Ryan Carboni , "tls@ietf.org" 
Date: Wed, 22 Oct 2014 18:12:07 -0400
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: Ac/uHcbNQfiM36NXRlOkxr3O9gHrQgAJz5wQ
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE0@USMBX1.msg.corp.akamai.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE0USMBX1msgcorp_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LRSnr55Ks1gsMb2HHE32PhYUW7Y
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 22:12:12 -0000

--_000_2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE0USMBX1msgcorp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QXR0YWNrcyBvbmx5IGdldCBiZXR0ZXIgd2hlbiB3ZSBsZWFybiBtb3JlIGFuZCBSQzQgd2lsbCBu
ZXZlciBiZSBicm9rZW4uDQoNCkRpZCBJIHN1bW1hcml6ZSB5b3UgYWNjdXJhdGVseT8NCg0KLS0N
ClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlciwgQWthbWFpIFRlY2hub2xvZ2llcw0KSU06IHJz
YWx6QGphYmJlci5tZTxtYWlsdG86cnNhbHpAamFiYmVyLm1lPiBUd2l0dGVyOiBSaWNoU2Fseg0K

--_000_2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE0USMBX1msgcorp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw
YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw
bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE
O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx
MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg
Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F
Ti1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkF0dGFja3Mgb25seSBnZXQgYmV0
dGVyIHdoZW4gd2UgbGVhcm4gbW9yZSBhbmQgUkM0IHdpbGwgbmV2ZXIgYmUgYnJva2VuLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE
Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7
Y29sb3I6IzFGNDk3RCc+RGlkIEkgc3VtbWFyaXplIHlvdSBhY2N1cmF0ZWx5PzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6
IzFGNDk3RCc+LS3CoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7Y29sb3I6IzFGNDk3RCc+UHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVyLCBBa2FtYWkg
VGVjaG5vbG9naWVzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiO2NvbG9yOiMxRjQ5N0QnPklNOiA8YSBocmVmPSJtYWlsdG86cnNhbHpAamFiYmVyLm1lIj5y
c2FsekBqYWJiZXIubWU8L2E+IFR3aXR0ZXI6IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+PC9w
PjwvZGl2PjwvYm9keT48L2h0bWw+

--_000_2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE0USMBX1msgcorp_--


From nobody Wed Oct 22 15:15:50 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720431A874D for ; Wed, 22 Oct 2014 15:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9WhImy6oVrP for ; Wed, 22 Oct 2014 15:15:45 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7E91A70E2 for ; Wed, 22 Oct 2014 15:15:45 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A85CB4756F; Wed, 22 Oct 2014 22:15:44 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5CB7B4758E; Wed, 22 Oct 2014 22:15:44 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 57FE58004E; Wed, 22 Oct 2014 22:15:44 +0000 (GMT)
Received: from usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 22 Oct 2014 18:15:43 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Wed, 22 Oct 2014 18:15:37 -0400
From: "Salz, Rich" 
To: Ryan Carboni , "tls@ietf.org" 
Date: Wed, 22 Oct 2014 18:15:36 -0400
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: Ac/uJz2z1r6R5tvTS32F4zDSxcxxvgAHljIw
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE2@USMBX1.msg.corp.akamai.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TJiURqwiHwo6qKWeykhCzcDXQZU
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 22:15:48 -0000

PiBSQzQgc2hvdWxkIGJlIGZ1bGx5IGRlcHJlY2F0ZWQuLi4gaW4gMjAyMC4NCg0KV2l0aCBhbGwg
ZHVlIHJlc3BlY3QsIG1vc3QgY3J5cHRvZ3JhcGhlcnMgd2hvIHdvcmsgd2l0aCB0aGUgSUVURiBk
aXNhZ3JlZSB3aXRoIHlvdS4NCg0KLS0gIA0KUHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVyLCBB
a2FtYWkgVGVjaG5vbG9naWVzDQpJTTogcnNhbHpAamFiYmVyLm1lIFR3aXR0ZXI6IFJpY2hTYWx6
DQo=


From nobody Wed Oct 22 15:19:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804C51A1B4F for ; Wed, 22 Oct 2014 15:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0apLeyZZ14V for ; Wed, 22 Oct 2014 15:18:58 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 2B88D1A1AFD for ; Wed, 22 Oct 2014 15:18:58 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B48AE475A5; Wed, 22 Oct 2014 22:18:57 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A81774759C; Wed, 22 Oct 2014 22:18:57 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id A400B202E; Wed, 22 Oct 2014 22:18:57 +0000 (GMT)
Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 22 Oct 2014 18:18:39 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 22 Oct 2014 18:18:39 -0400
From: "Salz, Rich" 
To: Nico Williams , "tls@ietf.org" 
Date: Wed, 22 Oct 2014 18:18:35 -0400
Thread-Topic: [TLS] Unifying tickets and sessions
Thread-Index: Ac/uKJhcvnpA1MDhTJO2cTepylyKWQAHU73Q
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE4@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/effunnAChJUqtP45RG0YA8W8-Tk
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 22:19:00 -0000

I understand the concern:  the ticket should be encrypted at least as stron=
gly as the bulk encryption of the traffic.

But that concern is misplaced (a server could have a one-time-pad and do XO=
R), and it is not up to the client to tell the server how to operate.  The =
client can always not send the ticket if it has concerns, and is able to ju=
stify/prove them.


-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Wed Oct 22 16:04:40 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624001AD409 for ; Wed, 22 Oct 2014 16:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiwJdufz6zeb for ; Wed, 22 Oct 2014 16:04:32 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA161A8755 for ; Wed, 22 Oct 2014 16:04:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 207E3BE11 for ; Thu, 23 Oct 2014 00:04:31 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcMSpVrSKisW for ; Thu, 23 Oct 2014 00:04:29 +0100 (IST)
Received: from [10.87.48.12] (unknown [86.41.59.37]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CE1F7BE10 for ; Thu, 23 Oct 2014 00:04:29 +0100 (IST)
Message-ID: <544837FD.202@cs.tcd.ie>
Date: Thu, 23 Oct 2014 00:04:29 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References:  <20141022175238.GF19158@mournblade.imrryr.org>
In-Reply-To: <20141022175238.GF19158@mournblade.imrryr.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uc4JDyq7fHCc2OR7OmaBwBNfS5o
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 23:04:38 -0000

Viktor,

On 22/10/14 18:52, Viktor Dukhovni wrote:
> On Wed, Oct 22, 2014 at 10:28:54AM -0700, Ryan Carboni wrote:
> 
>> This is why SHA-256 will never have a malicious collision, and why RC4 will
>> never be broken.
> 
> Well, never is a long time, and it is already somewhat broken, in that
> the bias in at least firt 256 bytes of output makes fixed plaintexts
> transmitted repeatedly under varying keys vulnerable to recovery.
> 
> While I would prefer to see RC4 phased out more gradually, I do
> not think we can claim that it has not been broken.
> 
> So I think that it would be nice if there was some wiggle-room for
> opportunistic TLS.  As weak as RC4 might be, it is stronger than
> cleartext.  And the published bias attacks don't apply to MTA to
> MTA SMTP.  There is no (pairwise) fixed sensitive plaintext at a
> fixed offset in every MTA to MTA email transaction.
> 
> I have no objections to banning RC4 for "strict" TLS use-cases.

I think there is a significant difference between the security
(in particular confidentiality) one gets with good and dodgy
algorithms which is sufficient to argue that the OS design
pattern is inappropriate to use with such dodgy algs.

The problem is if the ciphertext is recorded and if the alg
in question is broken in the near future in a ciphertext-only
attack then the result was the same as no confidentiality,
and was (post-facto but still in fact) not "better" security,
as per the OS design pattern. The nearer the "near future" the
more this applies. One might even meet people who might
speculate that the "near future" for academic cryptographers
could be the recent past for some government cryptographers.

So, it is entirely consistent to both promote OS and deprecate
RC4 in TLS if the WG chairs declare this has rough consensus.

I guess questioning the proximity of the "near future" in the
above argument is reasonable, but if, as I believe, the crypto
folk all tell us RC4 is now definitely past its sell-by date
then it's time for an RFC that deprecates that so that the
sensible use-by date hasn't yet again gone flying by with us
having said nothing. (And bear in mind that RFCs and BCPs are
nowhere near as normative as the sell-by date on your local
litre of milk;-)

Cheers,
S.


> 


From nobody Wed Oct 22 16:11:23 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C96E1A874B for ; Wed, 22 Oct 2014 16:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1bcJ7USetd4 for ; Wed, 22 Oct 2014 16:11:17 -0700 (PDT)
Received: from mx204.easyname.com (mx204.easyname.com [212.232.28.125]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3E61A8781 for ; Wed, 22 Oct 2014 16:11:15 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xh53f-0001M6-Un; Thu, 23 Oct 2014 01:11:14 +0200
Message-ID: <54483976.6090300@fussenegger.info>
Date: Thu, 23 Oct 2014 01:10:46 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Salz, Rich" , Nico Williams , "tls@ietf.org" 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org>  <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE4@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE4@USMBX1.msg.corp.akamai.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040000070605080401010103"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7I22_NiETMvkUtdJoLkwnVu8MAE
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 23:11:21 -0000

This is a cryptographically signed message in MIME format.

--------------ms040000070605080401010103
Content-Type: multipart/alternative;
 boundary="------------030405010108030008010008"

This is a multi-part message in MIME format.
--------------030405010108030008010008
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

On 10/23/2014 12:18 AM, Salz, Rich wrote:
> I understand the concern:  the ticket should be encrypted at least as s=
trongly as the bulk encryption of the traffic.

Exactly :)

> [=85] and it is not up to the client to tell the server how to operate.=
  The client can always not send the ticket if it has concerns, and is ab=
le to justify/prove them.
>

I never proposed that the client should do anything; not sending or even =

accepting tickets is what clients with concerns should do. Exactly as it =

is now!

Manuel's remarks to my original proposal are great additions to the=20
discussion=20
(http://www.ietf.org/mail-archive/web/tls/current/msg14048.html), so let =

me try to sum it up once more incorporating what he said and thought of.

Regarding https://tools.ietf.org/html/rfc5077#section-5.5

  * The server has a list of server-side supported cipher suites of
    which the strongest is using SUPER-CIPHER-9999. This means that ALL
    tickets/tokens **MUST** be encrypted with at least SUPER-CIPHER-9999
    on the server-side.
  * The server has a list of server-side supported cipher suites of
    which the strongest is using GENERIC-CIPHER-123. This means that ALL
    tickets/tokens **MUST** be encrypted with at least
    GENERIC-CIPHER-123 on the server-side.

  * It doesn't matter which cipher suite was actually used for the tunnel=
=2E
  * It doesn't matter which client it is.
  * Nothing of all that complexity matters!
  * The only thing that the server has to make sure is that it doesn't
    downgrade the strongest server-side supported/configured cipher.
    Simply saying that all tickets have to be (e.g.) AES-256 isn't going
    to cover it, because this would result in the same situation as we
    have it right now with OpenSSL and AES-128-CBC. It's like you said
    Rich, the RFC should stay silent on the actual algorithms that are
    used but it should ensure that developers aren't implementing
    something that will constantly downgrade encryption.

Regarding https://tools.ietf.org/html/rfc5077#section-5.6

  * The server **MUST NOT** have more than one encryption key which
    **MUST** be rotated (used as decryption key and replaced by a newly
    generated encryption key) or discarded after at least 24 hours after
    generation.
  * The server **MAY** have multiple decryption keys which **MUST** be
    discarded after at least 72 hours after generation.

Good example for clustering and rotation=20
https://blog.twitter.com/2013/forward-secrecy-at-twitter
Good example for how this proposal could be implemented was partly given =

by Viktor.

On a last note, I like the idea of derived keys but it makes clusters=20
much more complicated and I honestly don't think that this is necessary. =

With many possible algorithms to choose from, how could anyone know how=20
the ticket was actually encrypted? (Right now that would be easy to know.=
)

Richard

--------------030405010108030008010008
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    On 10/23/2014 12:18 AM, Salz, Rich wrote:

    

      
I understand the concern:  the ticket should be encr=
ypted at least as strongly as the bulk encryption of the traffic.


    

    

    Exactly :)

    

    

      
[=85] and it is not up to the client to tell the server how to operate.  =
The client can always not send the ticket if it has concerns, and is able=
 to justify/prove them.



    

    

    I never proposed that the client should do anything; not sending or
    even accepting tickets is what clients with concerns should do.
    Exactly as it is now!

    

    Manuel's remarks to my original proposal are great additions to the
    discussion
    (http://www.ietf.org/mail-archive/w=
eb/tls/current/msg14048.html), so
    let me try to sum it up once more incorporating what he said and
    thought of.

    

    Regarding https://tools.ietf.org/html/rfc5077#sect=
ion-5.5

    
    
      
  • The server has a list of server-side supported cipher suites
        of which the strongest is using SUPER-CIPHER-9999. This means
        that ALL tickets/tokens **MUST** be encrypted with at least
        SUPER-CIPHER-9999 on the server-side.
    • 
      
  • The server has a list of server-side supported cipher suites
        of which the strongest is using GENERIC-CIPHER-123. This means
        that ALL tickets/tokens **MUST** be encrypted with at least
        GENERIC-CIPHER-123 on the server-side.
    • 
    

    
    
      
  • It doesn't matter which cipher suite was actually used for the
        tunnel.
    • 
      
  • It doesn't matter which client it is.
    • 
      
  • Nothing of all that complexity matters!
    • 
      
  • The only thing that the server has to make sure is that it
        doesn't downgrade the strongest server-side supported/configured
        cipher. Simply saying that all tickets have to be (e.g.) AES-256
        isn't going to cover it, because this would result in the same
        situation as we have it right now with OpenSSL and AES-128-CBC.
        It's like you said Rich, the RFC should stay silent on the
        actual algorithms that are used but it should ensure that
        developers aren't implementing something that will constantly
        downgrade encryption.
    
      
    • 
    

    Regarding https://tools.ietf.org/html/rfc5077#sect=
ion-5.6

    
    
      
  • The server **MUST NOT** have more than one encryption key
        which **MUST** be rotated (used as decryption key and replaced
        by a newly generated encryption key) or discarded after at least
        24 hours after generation.
    • 
      
  • The server **MAY** have multiple decryption keys which
        **MUST** be discarded after at least 72 hours after generation.
    

    Good example for clustering and rotation
    https://blog.twitter.com/2013/forward-sec=
recy-at-twitter

    Good example for how this proposal could be implemented was partly
    given by Viktor.

    

    On a last note, I like the idea of derived keys but it makes
    clusters much more complicated and I honestly don't think that this
    is necessary. With many possible algorithms to choose from, how
    could anyone know how the ticket was actually encrypted? (Right now
    that would be easy to know.)

    

    Richard

  


--------------030405010108030008010008--

--------------ms040000070605080401010103
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjIyMzEwNDZaMCMGCSqGSIb3DQEJBDEWBBRrITI/ntoKBCjEtFZHl522+hcX7jBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEAX/wDj2YcJ2c7Xjgrg4Vb3jyUzC9g
bkQPk6GDn2daLlpJsKt1GlVqZX1tGj3e8iY7+E7qj++vHE/XiR2BqMaCCx+CgnRGsBsehub/
ee8OwDLM3mJ4eWudSIxuqPyrX2NajaZahLVx5oDjWqBLwOl0/edpjfK+5rUBj9GwUtaQuukC
9PnA59wjZpGk8MRVN+m+Eyn/4moWf1gdEkPshRzQOlOJVJhI/wMnu4MSw4fTyKbWKLEFIMR0
OAE55CKaz5eqr7c30BX9mj4000K6Of9iCGA+mfQgR8S0nrMzlrJYt3ihKk2zbLL/yIs0KFHr
ODK9KeA3J+BSoB/GqqJSfe8+sQAAAAAAAA==
--------------ms040000070605080401010103--


From nobody Wed Oct 22 16:22:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3608C1AD40F for ; Wed, 22 Oct 2014 16:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.997
X-Spam-Level: 
X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeDmn-VIimgt for ; Wed, 22 Oct 2014 16:22:33 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE8D1A87C8 for ; Wed, 22 Oct 2014 16:22:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=tsaPqgYOJEg95g4oVgN6/J8Y/UCTKw61WZS271Ce8yo=;  b=FSkz+Rp0tX1El+l1/R3zs6lQhrvMG0xrsQRBSarxsZi+TTZ8l9zCVqUlu50OlTsw63pCmw3AwBR6jnnIFjxgAaC0B8wfVvp89cLJWOWugxQL2vNj/a0KWEexgcg+TTMgBWq4V6RFhpoWljxgQ1yBqxiH7ODIpmFrlU+MFxO8MxU=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xh5EV-0007u6-CK; Thu, 23 Oct 2014 01:22:26 +0200
Message-ID: <54483C33.4000702@polarssl.org>
Date: Thu, 23 Oct 2014 01:22:27 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nico Williams , "tls@ietf.org" 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aYp8RDJa1VoYnoyzGct66-uI7Wg
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 23:22:35 -0000

On 22/10/2014 20:46, Nico Williams wrote:
> On Mon, Oct 20, 2014 at 6:58 PM, Viktor Dukhovni  wrote:
>> On Mon, Oct 20, 2014 at 11:39:31PM +0200, Manuel P?gouri?-Gonnard wrote:
>>> While I'm sympathetic with the goal, I'm afraid that will complicate
>>> implementations more than necessary. How about requiring to use a key length at
>>> least a high as the highest supported ciphersuite instead?
> 
> This is just as silly.  The server should choose what cipher to use, full stop.
> 
I'm afraid you didn't understand what I was actually trying to suggest, but my
sentence was ambiguous: my suggestion was that the server choose what cipher to
use, by looking at what ciphersuites it is prepared to negotiate, and then
picking the most secure symetric cipher from this list (or one of those with
maximal key size).

Eg, if a server is only going to negotiate 128-bit suites because it thinks it's
enough and doesn't want to waste cycles on more than that, then encrypting the
tickets with a 128-bit key is fine. If it is prepared to negotiate 256-bit suite
with some clients, it should encrypt the tickets with a 256-bit key.

Manuel.


From nobody Wed Oct 22 16:27:14 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDC41A87A3 for ; Wed, 22 Oct 2014 16:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-9yz3njtQpB for ; Wed, 22 Oct 2014 16:27:12 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DE01A8781 for ; Wed, 22 Oct 2014 16:27:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=CWSyRFIXhyeBaOjB8bID69h249YuK7VbPllgXIG8EB4=;  b=oWqJ+B3/4xKJQfQhCYaEHTcAAW3hsmMO6JXJ6oFkTnqABwte17D3oIwlZjOV7tjF+B0nhH/OxmCpYKZaE+g99rn8fNKR6ly/KcT4B5bqh+JpsBo7GumbX0qvsu+6YyKcY/9dsb3pu4mviDjBXB1NmW/8FAHtWx1if7fMbm8sqgM=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xh5J3-0007uc-0Q; Thu, 23 Oct 2014 01:27:05 +0200
Message-ID: <54483D4C.9060809@polarssl.org>
Date: Thu, 23 Oct 2014 01:27:08 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Salz, Rich" , Nico Williams , "tls@ietf.org" 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org>  <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE4@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE4@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Rw9KiYiVuJJxAZDtTPy7_iM81Po
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 23:27:13 -0000

On 23/10/2014 00:18, Salz, Rich wrote:
> I understand the concern:  the ticket should be encrypted at least as
> strongly as the bulk encryption of the traffic.
> 
Yep.

> But that concern is misplaced (a server could have a one-time-pad and do
> XOR), and it is not up to the client to tell the server how to operate.  The
> client can always not send the ticket if it has concerns, and is able to
> justify/prove them.
> 
I don't think this is correct. Once the server emits the ticket (if we're
speaking about a ticket that contains session state including the MS), it's out
there in the clear* for an attacker to play with. That the client chooses to
ignore the ticket doesn't change that fact.

The server is fully responsible of protecting key material and not sending it
with a protection much weaker than the one used for the traffic.

* For TLS 1.2 I mean. For 1.3 that might be different.

Manuel.


From nobody Wed Oct 22 20:57:01 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935711A8899 for ; Wed, 22 Oct 2014 20:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7NpBw6XIYfh for ; Wed, 22 Oct 2014 20:56:58 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EC71A8887 for ; Wed, 22 Oct 2014 20:56:57 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id hz20so153752lab.39 for ; Wed, 22 Oct 2014 20:56:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SM+ILqAdxBMfnTw7RpcTISZ99MoWduy3KrWRZ/KCPgA=; b=pUAuoFWCbyW2dpjFlfDSYC7Yfxx5F9bgziC7N+Kb+h9kdDKcVeguvV0GOzchIYk6r8 lPb9yuU42Kxtewcmz4ZEh3DHWou4IQa5aub8NpHSBVxk5EuYrVTMoacl9QIZc49a3PvT JpeaaMNNpeml5c27Skh9yFj6PNWff8KPtb1KApUDURqWo3kWUa54IcESq7bpd8sR1RO4 zkfQPyTMh1OEP6nOsnobbiMeErRlp0CHDUC2gKDcVs9mXUjSHDkCzrbCbJBFHFtBEI5v 87WK+6NCcJ7Ye6giouj/vEqpdMkpCWLIr/2CsDe2U+j5CBw9+KtBKEVUHLaVRWrh/kiS VWtA==
MIME-Version: 1.0
X-Received: by 10.112.52.33 with SMTP id q1mr2196410lbo.42.1414036616155; Wed, 22 Oct 2014 20:56:56 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Wed, 22 Oct 2014 20:56:56 -0700 (PDT)
In-Reply-To: <54483976.6090300@fussenegger.info>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org>  <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE4@USMBX1.msg.corp.akamai.com> <54483976.6090300@fussenegger.info>
Date: Wed, 22 Oct 2014 20:56:56 -0700
Message-ID: 
From: Martin Thomson 
To: Richard Fussenegger 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/05xpdIG9HGyUCidR8gRs1d8r6IM
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 03:56:59 -0000

On 22 October 2014 16:10, Richard Fussenegger  wrote:
> MUST

The only concern here is your insistence on the use of that word,
particularly in the captilized form.

I don't think that anyone objects to a recommendation of the sort you
describe.  I suspect that many will happily acknowledge that using the
weakest cipher on offer isn't advisable either, since the floor on
cipher acceptance is unfortunately low due to a pressure on servers to
be maximally compatible.  So we can *recommend* the use of the
strongest cipher a server is willing to apply.  ...and RFC 5077 pretty
much says that (and more).

But your requirement remains completely unverifiable and therefore
unenforceable.  Using "MUST" is threatening to use a weapon you
provably cannot use.


From nobody Wed Oct 22 22:06:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D9A1A88BA for ; Wed, 22 Oct 2014 22:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXlaAouPDSPP for ; Wed, 22 Oct 2014 22:06:41 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0687.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::687]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BD01A88CA for ; Wed, 22 Oct 2014 22:06:41 -0700 (PDT)
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) with Microsoft SMTP Server (TLS) id 15.1.6.9; Thu, 23 Oct 2014 05:06:17 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0006.000; Thu, 23 Oct 2014 05:06:17 +0000
From: "Paterson, Kenny" 
To: "Salz, Rich" 
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: AQHP7icc3ylV2R9PMkuBCA/OeAIlpJw8rxoAgAByvh0=
Date: Thu, 23 Oct 2014 05:06:17 +0000
Message-ID: 
References: ,  <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE2@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE2@USMBX1.msg.corp.akamai.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [82.132.231.106]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB383;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(51704005)(24454002)(189002)(87936001)(85306004)(19580405001)(19580395003)(85852003)(64706001)(2656002)(83716003)(36756003)(106356001)(230783001)(95666004)(76482002)(110136001)(31966008)(80022003)(92726001)(50986999)(99396003)(76176999)(54356999)(101416001)(33656002)(46102003)(21056001)(120916001)(74482002)(122556002)(82746002)(20776003)(106116001)(105586002)(97736003)(40100003)(92566001)(66066001)(558084003)(86362001)(4396001)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB383; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zUuM9uw9YnM-F0RIJsOM-uFG3S0
Cc: "tls@ietf.org" , Ryan Carboni 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 05:06:44 -0000

On 22 Oct 2014, at 23:16, "Salz, Rich"  wrote:

>> RC4 should be fully deprecated... in 2020.
>=20
> With all due respect, most cryptographers who work with the IETF disagree=
 with you.
>=20

Like me, for instance. =


From nobody Wed Oct 22 23:00:09 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA771A88D9 for ; Wed, 22 Oct 2014 23:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_yjWpSnRGI8 for ; Wed, 22 Oct 2014 23:00:06 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2668B1A1B6F for ; Wed, 22 Oct 2014 23:00:06 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E0CB52AB2E7; Thu, 23 Oct 2014 06:00:03 +0000 (UTC)
Date: Thu, 23 Oct 2014 06:00:03 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141023060003.GM19158@mournblade.imrryr.org>
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <544837FD.202@cs.tcd.ie>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LByaev90hK1hARu8K-ZfAPZdICY
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 06:00:08 -0000

On Thu, Oct 23, 2014 at 12:04:29AM +0100, Stephen Farrell wrote:

> > So I think that it would be nice if there was some wiggle-room for
> > opportunistic TLS.  As weak as RC4 might be, it is stronger than
> > cleartext.  And the published bias attacks don't apply to MTA to
> > MTA SMTP.  There is no (pairwise) fixed sensitive plaintext at a
> > fixed offset in every MTA to MTA email transaction.
> > 
> > I have no objections to banning RC4 for "strict" TLS use-cases.
> 
> I think there is a significant difference between the security
> (in particular confidentiality) one gets with good and dodgy
> algorithms which is sufficient to argue that the OS design
> pattern is inappropriate to use with such dodgy algs.

I'd very much like to agree with you this year.  My concern is that
for now, there are still too many RC4-only sites, and disabling
RC4 will do more harm (in opportunistic TLS) than good in two ways:

    * Some communication will needlessly fall back to cleartext
      after STARTTLS fails, which might have succeeded with RC4.

    * Some communication will not fall back, and force users to
      statically downgrade transmission to cleartext by policy.
      Said policy will rarely get reviewed, and the RC4-only peers
      will be "pinned" at cleartext even after they upgrade.

Thus, while I am 100% for deprecation of RC4, the first step before
banning is I think a less radical phase-out.  With a bit of luck
sensible SMTP administrators will ignore the draft MUST NOT USE
language, and will instead arrange for RC4 to be a last-resort.
A few years from now, RC4 use will truly be negligible, and we can
start removing support.

If excluding opportunistic security is too painful, and it is better
for the draft to have an undiluted message than a nuanced one based
on more pragmatic considerations, fine, so be it, make it pure.
We'll muddle along violating it as necessary.

-- 
	Viktor.

P.S.  More eloborate TL;DR observations:

While I've largely eliminated inbound RC4 for my domain by configuring
the SMTP server to override client cipher suite preference with
more sensible settings on the server, I'm still sending out some
RC4 traffic, because Gmail overrides my client's cipherlist order
and elects ECDHE-RSA-RC4-SHA first.

If Google has not yet got the memo, it is perhaps premature to
expect the rest of the world to be ready.

If the draft goes ahead as-is, I'm of course prepared to offer
people advice on when/how to ignore its requirements, if needed to
resolve operational issues, but would prefer to not have to do
that.

I'd prefer to see a ban on RC4 for opportunistic uses a few years
after it is successfully eliminated for "strict TLS" and largely
phased out in opportunistic use with preference for RC4 over AES
disabled at most sites (more hardware AES support, fewer ancient
systems, ...).

At the end of the day, sure banning RC4 outright would not be
tragic.  People will largely continue to do what they're doing
today, and will generally only implement changes as part of software
upgrade cycles.

This means, for example, that if RC4 disappears from OpenSSL's
"DEFAULT" cipher list on the "master" (future 1.1.0) branch, and
OpenSSL 1.1.0 is released some time in 2015, operating system
releases might make this available to users in 2016, and users will
begin to adopt this in noticeable numbers by 2018.

So RC4 is likely with us through 2020, no matter what the RFC says.

Thus, for what it's worth, I am trying to prevent ~5 years of undue
pressure on thinking administrators from unthinking auditors.  By
2020, opportunistic TLS should I expect be ready to begin running
RC4-free.


From nobody Thu Oct 23 00:08:43 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A451A0377 for ; Thu, 23 Oct 2014 00:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24f6DcwDhbKj for ; Thu, 23 Oct 2014 00:08:38 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id B91BE1A8901 for ; Thu, 23 Oct 2014 00:08:38 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1E02B2852C for ; Thu, 23 Oct 2014 07:08:38 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 09C9728524 for ; Thu, 23 Oct 2014 07:08:38 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 04202202E for ; Thu, 23 Oct 2014 07:08:38 +0000 (GMT)
Received: from usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 23 Oct 2014 03:08:37 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Thu, 23 Oct 2014 03:08:36 -0400
From: "Salz, Rich" 
To: "tls@ietf.org" 
Date: Thu, 23 Oct 2014 03:08:35 -0400
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: Ac/uhqdsbumw/5GvSRWpm/eFMP6+BwACWBkg
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64F14@USMBX1.msg.corp.akamai.com>
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <20141023060003.GM19158@mournblade.imrryr.org>
In-Reply-To: <20141023060003.GM19158@mournblade.imrryr.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JYls70xC__9kVWVffNyhicVXrKE
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 07:08:40 -0000

> If excluding opportunistic security is too painful, and it is better for =
the draft
> to have an undiluted message than a nuanced one based on more pragmatic
> considerations, fine, so be it, make it pure.
> We'll muddle along violating it as necessary.

I believe this is the consensus.


From nobody Thu Oct 23 02:43:08 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154311A89FA for ; Thu, 23 Oct 2014 02:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3u0-wMYD0mP for ; Thu, 23 Oct 2014 02:43:03 -0700 (PDT)
Received: from mx201.easyname.com (mx201.easyname.com [212.232.28.122]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713711A89AF for ; Thu, 23 Oct 2014 02:43:02 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XhEv3-0000Nm-I3; Thu, 23 Oct 2014 11:42:59 +0200
Message-ID: <5448CD89.1070903@fussenegger.info>
Date: Thu, 23 Oct 2014 11:42:33 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Martin Thomson , "tls@ietf.org" 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>	<5445775E.3050108@fussenegger.info>	<54458113.1050304@polarssl.org>	<20141020235832.GK19158@mournblade.imrryr.org>		<2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE4@USMBX1.msg.corp.akamai.com>	<54483976.6090300@fussenegger.info> 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030907010206060608080505"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OdApoEtZ7Pk-Lo-jlUOuDW2BBbA
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 09:43:06 -0000

This is a cryptographically signed message in MIME format.

--------------ms030907010206060608080505
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 10/23/2014 5:56 AM, Martin Thomson wrote:
> On 22 October 2014 16:10, Richard Fussenegger  wrote:
>> MUST
> The only concern here is your insistence on the use of that word,
> particularly in the captilized form.

Not insisting, you're the first to raise concerns in this regard and we=20
should of course discuss that if it's the problem with the proposal.

> ...and RFC 5077 pretty much says that (and more).

Yes, but the result of these recommendations is that implementations are =

always using AES-128-CBC and ignoring any supported ciphers (that's the=20
concern here at hand).

> But your requirement remains completely unverifiable and therefore
> unenforceable.

What exactly is unverifiable?

> =E2=80=9C[=E2=80=A6] the ticket key might be weaker than the cipher use=
d for the=20
> connection. For example, OpenSSL uses 128-bit AES keys for this purpose=
=2E=E2=80=9D
> =E2=80=94Ivan Risti=C4=87: =E2=80=9CBulletproof SSL and TLS=E2=80=9D, p=
=2E 58, online:=20
> https://www.feistyduck.com/books/bulletproof-ssl-and-tls/

> =E2=80=9C128 bit of security is all you get (at best), regardless of th=
e=20
> cipher which has been negociated=E2=80=9D [sic!]
> =E2=80=94Florent Daigniere: =E2=80=9CTLS =E2=80=9CSecrets=E2=80=9D=E2=80=
=9D, p. 8, online:=20
> https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-WP.pdf

> =E2=80=9CThe encryption of the SessionTicket depends on 128-bit AES wit=
h the=20
> IV fi=1Celd.=E2=80=9D
> =E2=80=94Joey Dreijer and Sean Rijs: =E2=80=9CPerfect forward not so se=
crecy=E2=80=9D, p. 6,=20
> online:=20
> https://os3.nl/_media/2013-2014/courses/ssn/projects/perfect_forward_no=
t_so_secrecy_report.pdf

Richard


--------------ms030907010206060608080505
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjMwOTQyMzNaMCMGCSqGSIb3DQEJBDEWBBQuG6SjoVvA47jxMIW0c6l0HdzBrjBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEALQorLSyNgRreU+iXn75fTttlweYc
wHOxPY/Z9R6e4sdXee/osc750BAv7QNJNN1zTl5dWqUpEtFNH/qnXT5958NcZhTUd69jjCgE
J3Fazd2jpv71kqjM45g+t32TBNGkeTJG17bSbbPb52cLJFpJ3cAoI95v3/VdS4tSglvxn7K2
fzcC7Bga4k1DS3S98+u3JIhmLHbfadPENChmanxvAlD/c1l+opHUy7u+F9aCrENm5obMSLDv
2ejLdrf8TsxHelIB+ZVjt3S4WsGQnlAtCpVHRn3zKuw2lLRJUj2kTK3aKw8Bs716GgQJUzp7
Nw9UjOUIJmeMjIPezLJs2jCgbwAAAAAAAA==
--------------ms030907010206060608080505--


From nobody Thu Oct 23 06:34:08 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505491A1A72 for ; Thu, 23 Oct 2014 06:34:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE_eBeMhv9YO for ; Thu, 23 Oct 2014 06:34:04 -0700 (PDT)
Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F5B1A90C0 for ; Thu, 23 Oct 2014 06:34:04 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id rd18so416743iec.27 for ; Thu, 23 Oct 2014 06:34:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=d9TzebdHiA2vr6fOC29wuWzJ9N7PkIVuFlQsiSS4RtQ=; b=L7GJ26hNqfvlGRqc3dx8wVSdTHZuw1Lm5Y85xNpyWcpUxuEPp4/zqh3U3MgBHDcwjP L1j34yn9noxLYsya5wHcoaihXbgQWKUDHR1cJsk8PxeGJC9gNUebzcPxsQuif4tEj1um v83OwwaXwb8v5OgrNULLLWuw3UKFJjC3n8KYilobUYDdMOoSOQu6k5QEw3VL9AU0ZAlh yLYJBu7XqhWFnI1cjjdpUOvSuCOunglb3z5z/4Q+dLwlNa/er6ntfkVhsd6lrD4GQD0T ul/02faHNibiD5k63z4SbdFu9WyC9L0TNfXGx1IVVbsdAcUX+rmj3o7fg0liixxzywrF SkAA==
X-Gm-Message-State: ALoCoQm1ckw5UXqkJboDIYU6rZlqM0WcDMJzSyfxQQ1x1sDZu4dsTQrzC3T7KccnBdSc7D63k6ok
X-Received: by 10.50.134.131 with SMTP id pk3mr41034841igb.6.1414071243851; Thu, 23 Oct 2014 06:34:03 -0700 (PDT)
Received: from [192.168.10.231] ([194.154.214.214]) by mx.google.com with ESMTPSA id f71sm837031ioe.28.2014.10.23.06.34.02 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Oct 2014 06:34:03 -0700 (PDT)
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <544606E5.2070807@fussenegger.info>  <1659862.HPNNz8lRhl@pintsize.usersys.redhat.com> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <28F97438-9D8D-40C4-9A99-AC8CF3183787@azet.org>
X-Mailer: iPhone Mail (12A405)
From: Aaron Zauner 
Date: Thu, 23 Oct 2014 15:34:01 +0200
To: David Leon Gil 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZkRscdgLH0Hmsv3UAzZ6PhxOTVk
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 13:34:06 -0000

hi *,

i really like the initial suggestion by rich salz.


> On 22.10.2014, at 16:27, David Leon Gil  wrote:
>=20
> There are, obviously, two things a server should be able to use for a
> unified session id/ticket:
>=20
> - An opaque identifier
> - Encrypted session state using a construction like RFC 5077's.
>=20
> Right now, RFC 5077 recommends: AES-128 with a 128-bit key and
> HMAC-SHA256 with a 256-bit key
hash functions have n/2 security.=20

>=20
> Or, uselessly high 256-bit security against active attackers, and
> uselessly low 128-bit security strength against global passive
> adversaries.
>=20
> There should be a recommended session ticket construction at a 256 bit
> security strength for privacy to replace RFC 5077 s.4's.
>=20
> --
>=20
>> On Wed, Oct 22, 2014 at 8:56 AM, Hubert Kario  wrote:
>> That assumes that you have the space to store all those communications,
>=20
> I frankly don't understand this.
>=20
> According to the newspapers, at least, the NSA *does* store *all*
> encrypted communications pending eventual decryption. So evidently
> they do, at least.
>=20
>> then you need to have the ability to reference all those 2^50 keys in clo=
se to real time.
>=20
> This is a few petabytes of data, or a few thousand 1 TB SSDs. This is
> not a large amount of data.
>=20
>> Yes, it doesn't require "hard" computation, but it does require massive
>> amounts of relatively fast memory.
>=20
> No. It doesn't. It requires less than one cipher block per key for
> most of the computation. (The main expense is memory bandwidth.)
>=20
>> It's a classic memory-time tradeoff, isn't it?
>=20
> No. The gains are better than linear. See
> http://cr.yp.to/snuffle/bruteforce-20050425.pdf, but for "circuit"
> read "graphics card/SPU/MIC".

it's more likely that they'd use specially designed integrated circuits/ASIC=
s/FPGAs - if you use google you'll even find companies that sell these to 'g=
overnment'.

as somebody also working in HPC: the real tradeoff is still time/energy/mone=
y. how much does one want to spend for a single decrypted communication?

btw: the whole quantum discussion is just out of place here;
1) we're far far far away from a feasible solution. yeah all that media cove=
rage sounds dangerous; that doesn't make it real
2) implementations
3) the appropriate reaction should be to use post-quantum crypto algorithms i=
nstead of doubling the keysize for existing ones. I don't know of any algori=
thm that can be used for a protocol like TLS as of now.

(mobile)

Aaron

>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo


From nobody Thu Oct 23 06:36:42 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD47C1A1A72 for ; Thu, 23 Oct 2014 06:36:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.212
X-Spam-Level: 
X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSN7pQOVk71g for ; Thu, 23 Oct 2014 06:36:36 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3641A90C2 for ; Thu, 23 Oct 2014 06:36:36 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NDaaUZ012148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 23 Oct 2014 09:36:36 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9NDaXUL000459 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 23 Oct 2014 09:36:35 -0400
Message-ID: <1414071393.2511.16.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: "tls@ietf.org" 
Date: Thu, 23 Oct 2014 15:36:33 +0200
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xXY6H4yelCIGl6AyPIFqHV2muX0
Subject: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 13:36:39 -0000

Hello,
 Is there some public server implementing rfc7366? At some point the
server at eid.vx4.net was sent as one, but it doesn't seem to implement
the protocol in the published rfc (the NSS people seem to have noticed
that [0], and my tests agree).

regards,
Nikos

[0]. https://bugzilla.mozilla.org/show_bug.cgi?id=972145



From nobody Thu Oct 23 06:48:39 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AEB1A8AFE for ; Thu, 23 Oct 2014 06:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kgs6UFetU-pm for ; Thu, 23 Oct 2014 06:48:33 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96951A90F3 for ; Thu, 23 Oct 2014 06:48:31 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NDVRLZ014226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 23 Oct 2014 09:31:28 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9NDVPxR001887 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2014 09:31:26 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Thu, 23 Oct 2014 15:31:24 +0200
Message-ID: <2692021.SmcXNkosgU@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <20141023060003.GM19158@mournblade.imrryr.org>
References:  <544837FD.202@cs.tcd.ie> <20141023060003.GM19158@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dI5bcPTbCKeZa6QYi4rnqJKU_ec
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 13:48:36 -0000

On Thursday 23 October 2014 06:00:03 Viktor Dukhovni wrote:
> On Thu, Oct 23, 2014 at 12:04:29AM +0100, Stephen Farrell wrote:
> > > So I think that it would be nice if there was some wiggle-room for
> > > opportunistic TLS.  As weak as RC4 might be, it is stronger than
> > > cleartext.  And the published bias attacks don't apply to MTA to
> > > MTA SMTP.  There is no (pairwise) fixed sensitive plaintext at a
> > > fixed offset in every MTA to MTA email transaction.
> > > 
> > > I have no objections to banning RC4 for "strict" TLS use-cases.
> > 
> > I think there is a significant difference between the security
> > (in particular confidentiality) one gets with good and dodgy
> > algorithms which is sufficient to argue that the OS design
> > pattern is inappropriate to use with such dodgy algs.
> 
> I'd very much like to agree with you this year.  My concern is that
> for now, there are still too many RC4-only sites, and disabling
> RC4 will do more harm (in opportunistic TLS) than good in two ways:
> 
>     * Some communication will needlessly fall back to cleartext
>       after STARTTLS fails, which might have succeeded with RC4.
> 
>     * Some communication will not fall back, and force users to
>       statically downgrade transmission to cleartext by policy.
>       Said policy will rarely get reviewed, and the RC4-only peers
>       will be "pinned" at cleartext even after they upgrade.

Looking at web servers, less than 1% support only RC4 ciphers, the
rest of the 21% that end up negotiating RC4 will gladly negotiate
different ciphers (mostly AES based ones) if the client doesn't offer
RC4.

> If excluding opportunistic security is too painful, and it is better
> for the draft to have an undiluted message than a nuanced one based
> on more pragmatic considerations, fine, so be it, make it pure.
> We'll muddle along violating it as necessary.

How long since we got to know that RC4 is really bad? And this draft
is still not an RFC. Let's say that we will change it to say that the RC4 MUST 
be placed last (both client and server side) and release it today. How long 
will it take to release a new RFC that says that it MUST NOT be used?
How long will it take for majority (let's say 75%) of server admins that are 
not compliant with it to actually implement this policy? How many of them will 
unknowingly ignore it?

Just those issues in itself will cause the RC4 depreciation to have a de facto 
transition period. Just look for statistics of the OpenSSL CCS and Hartbleed 
fixes deployments, and those were security vulnerabilities, not best practice 
recommendations.

Second issue is that opportunistic encryption is completely vulnerable to 
active MITM attack, isn't it? This in itself makes it non-RFC compliant, at 
the very least, from the TLS point of view.

-- 
Regards,
Hubert Kario


From nobody Thu Oct 23 07:03:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05CF1A9119 for ; Thu, 23 Oct 2014 07:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.312
X-Spam-Level: 
X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xdv_ntLb_wJm for ; Thu, 23 Oct 2014 07:03:20 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB671A90E7 for ; Thu, 23 Oct 2014 07:03:20 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NE3IrC017841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 23 Oct 2014 10:03:19 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9NE3HnZ032216 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 23 Oct 2014 10:03:18 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Thu, 23 Oct 2014 16:03:16 +0200
Message-ID: <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <54483C33.4000702@polarssl.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QxfsVSTBWwvugDOmOArdjIRvIoI
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 14:03:22 -0000

On Thursday 23 October 2014 01:22:27 Manuel P=E9gouri=E9-Gonnard wrote:=

> On 22/10/2014 20:46, Nico Williams wrote:
> > On Mon, Oct 20, 2014 at 6:58 PM, Viktor Dukhovni =20
wrote:
> >> On Mon, Oct 20, 2014 at 11:39:31PM +0200, Manuel P?gouri?-Gonnard =
wrote:
> >>> While I'm sympathetic with the goal, I'm afraid that will complic=
ate
> >>> implementations more than necessary. How about requiring to use a=
 key
> >>> length at least a high as the highest supported ciphersuite inste=
ad?
> >=20
> > This is just as silly.  The server should choose what cipher to use=
, full
> > stop.
> I'm afraid you didn't understand what I was actually trying to sugges=
t, but
> my sentence was ambiguous: my suggestion was that the server choose w=
hat
> cipher to use, by looking at what ciphersuites it is prepared to nego=
tiate,
> and then picking the most secure symetric cipher from this list (or o=
ne of
> those with maximal key size).
>=20
> Eg, if a server is only going to negotiate 128-bit suites because it =
thinks
> it's enough and doesn't want to waste cycles on more than that, then
> encrypting the tickets with a 128-bit key is fine. If it is prepared =
to
> negotiate 256-bit suite with some clients, it should encrypt the tick=
ets
> with a 256-bit key.

While it may negotiate AES-256 (because it wants to interoperate with c=
lients=20
that are configured to not to present weaker ciphers), doesn't mean tha=
t it as=20
a whole is configured to the 256 bit level of security.

With TLS1.2 it may sign the (EC)DHE parameters using SHA-1, it may use =
RSA key=20
exchange using only 2048 bit keys, it may be just a local proxy server =
that is=20
hard coded to connect using AES-128 with the backed servers over open=20=

Internet.

Yes, server should encrypt the tickets with as strong algorithm as its =
most=20
secure cipher, but there are many situations where it's not necessary. =
"MUST"=20
is certainly not applicable.

--=20
Regards,
Hubert Kario


From nobody Thu Oct 23 07:22:08 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8071B1A8F4B for ; Thu, 23 Oct 2014 07:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSrkWxq8De64 for ; Thu, 23 Oct 2014 07:22:05 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8C11A8F35 for ; Thu, 23 Oct 2014 07:22:05 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6982F2AB2EF; Thu, 23 Oct 2014 14:22:04 +0000 (UTC)
Date: Thu, 23 Oct 2014 14:22:04 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141023142204.GN19158@mournblade.imrryr.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <544606E5.2070807@fussenegger.info>  <1659862.HPNNz8lRhl@pintsize.usersys.redhat.com>  <28F97438-9D8D-40C4-9A99-AC8CF3183787@azet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <28F97438-9D8D-40C4-9A99-AC8CF3183787@azet.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/g2q7MzWETh_m2g9WmOQjOqmx29w
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 14:22:06 -0000

On Thu, Oct 23, 2014 at 03:34:01PM +0200, Aaron Zauner wrote:

> > Right now, RFC 5077 recommends: AES-128 with a 128-bit key and
> > HMAC-SHA256 with a 256-bit key
>
> hash functions have n/2 security. 

The n/2 is collision resistance.  Here the hash function is used
in an HMAC construction.  I don't believe that n/2 applies for
HMAC-SHA2-256.

-- 
	Viktor.


From nobody Thu Oct 23 07:22:12 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD061A8F35 for ; Thu, 23 Oct 2014 07:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JzOUMxNfaU5 for ; Thu, 23 Oct 2014 07:22:04 -0700 (PDT)
Received: from mx206.easyname.com (mx206.easyname.com [212.232.25.162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B941A903D for ; Thu, 23 Oct 2014 07:22:04 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XhJH5-0000Dh-KK for tls@ietf.org; Thu, 23 Oct 2014 16:22:02 +0200
Message-ID: <54490EEF.1010008@fussenegger.info>
Date: Thu, 23 Oct 2014 16:21:35 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <544606E5.2070807@fussenegger.info>  <1659862.HPNNz8lRhl@pintsize.usersys.redhat.com>  <28F97438-9D8D-40C4-9A99-AC8CF3183787@azet.org>
In-Reply-To: <28F97438-9D8D-40C4-9A99-AC8CF3183787@azet.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080001010003060803090609"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VHKmZo-0mqBiDJYSaJ5Hu7XC8N4
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 14:22:08 -0000

This is a cryptographically signed message in MIME format.

--------------ms080001010003060803090609
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

On 10/23/2014 3:34 PM, Aaron Zauner wrote:
> 3) the appropriate reaction should be to use post-quantum crypto algori=
thms instead of doubling the keysize for existing ones. I don't know of a=
ny algorithm that can be used for a protocol like TLS as of now.

NTRU [1][2] is the only one that is said to be post-quantum [3][4] and=20
it even has a library [5] and seems to have very good performance [6][7].=


Richard

[1] https://tools.ietf.org/html/draft-ietf-tls-ntru-00
[2] https://en.wikipedia.org/wiki/NTRUEncrypt
[3]=20
http://middleware.internet2.edu/idtrust/2009/papers/07-perlner-quantum.pd=
f
[4]=20
http://94.242.221.125/bookreader.php/135832/Bernstein_-_Post_Quantum_Cryp=
tography.pdf
[5] http://www.yassl.com/yaSSL/Home.html
[6]=20
https://www.securityinnovation.com/uploads/ntru_speed_benchmark_research.=
pdf
[7] http://paper.ijcsns.org/07_book/200708/20070812.pdf


--------------ms080001010003060803090609
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjMxNDIxMzVaMCMGCSqGSIb3DQEJBDEWBBQKcl7lT8Bfhf6+x0A39oyAsxSWqzBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEALMPNMlCvnlY+e267JxvNSgutsaSs
WbTQHkotUqtq9BLQoaTuPmftvYDvR6MLgAakzoEviP0Ukt3UshTz69IHs8eyJ8WRtYBpQhPC
Wcq1RM165vYzxk9KW+19bQi0oUQ19lTtcEhWcEhJHo9t8QGuSMqr2SIl2FzZAmpVjeIGB4dL
RDbL3IDLXptALQp6WE0Urux3QLTHZb3Iqbz7YFA+vOyfr69azVbxGIGFGmFHpgTX7bTatbDy
87GDe3mY6vRKdC/Qqx1ZDgUY2/VrNGqfZM0YNoYakOsvxZRy6u58rM/Se3wWODe4dX2s6GdY
XaF9BhrdwYt8PIGUOj75ptJ7qQAAAAAAAA==
--------------ms080001010003060803090609--


From nobody Thu Oct 23 07:26:14 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6591A90DA for ; Thu, 23 Oct 2014 07:26:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTimYe3DOsh1 for ; Thu, 23 Oct 2014 07:26:11 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447DD1A9039 for ; Thu, 23 Oct 2014 07:26:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=TwSL6kYHL1EwIhhhrShBXLJn4kpnebj5GOm4PCRperY=;  b=h0FECej9DTPXzm7onCUKUSdLe7yshEDQpCMrjfQcUVi5Ney+nj2FUuXdk7/Vismm3EORVyl5+Rq7EFKcw0aRZJ7X9CHcYfmiXFfmIAupidcwAjPkLIIBuHpdUJzcNx+AMHDsDaVYs7+WEajSw8uUoT6bZsTt4/Ac+Fhd7lOBGMo=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XhJL1-0000ce-QI; Thu, 23 Oct 2014 16:26:04 +0200
Message-ID: <54490FFF.60706@polarssl.org>
Date: Thu, 23 Oct 2014 16:26:07 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Hubert Kario , tls@ietf.org
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com>
In-Reply-To: <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7MK5lYIDpqlNSUCnmmzaVn6eaN4
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 14:26:12 -0000

On 23/10/2014 16:03, Hubert Kario wrote:
> On Thursday 23 October 2014 01:22:27 Manuel Pégourié-Gonnard wrote:
>> Eg, if a server is only going to negotiate 128-bit suites because it thinks
>> it's enough and doesn't want to waste cycles on more than that, then
>> encrypting the tickets with a 128-bit key is fine. If it is prepared to
>> negotiate 256-bit suite with some clients, it should encrypt the tickets
>> with a 256-bit key.
> 
> While it may negotiate AES-256 (because it wants to interoperate with clients 
> that are configured to not to present weaker ciphers), doesn't mean that it as 
> a whole is configured to the 256 bit level of security.
> 
> With TLS1.2 it may sign the (EC)DHE parameters using SHA-1, it may use RSA key 
> exchange using only 2048 bit keys, it may be just a local proxy server that is 
> hard coded to connect using AES-128 with the backed servers over open 
> Internet.
> 
Yes, good points.

> Yes, server should encrypt the tickets with as strong algorithm as its most 
> secure cipher, but there are many situations where it's not necessary. "MUST" 
> is certainly not applicable.
> 
I agree, and I'm not advocating for a MUST.

Manuel.


From nobody Thu Oct 23 07:31:43 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D401A9234 for ; Thu, 23 Oct 2014 07:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlE6p5shKI2w for ; Thu, 23 Oct 2014 07:31:35 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFED1A9023 for ; Thu, 23 Oct 2014 07:31:34 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NDmo3Q031132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 23 Oct 2014 09:48:50 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9NDmmeU026583 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2014 09:48:50 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Thu, 23 Oct 2014 15:48:47 +0200
Message-ID: <1956811.gQP5ABpcIW@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <20141022190937.GI19158@mournblade.imrryr.org>
References:  <5447FA87.40007@fussenegger.info> <20141022190937.GI19158@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6EdvDE5owDJkH7oxHaZfS5tqT3k
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 14:31:41 -0000

On Wednesday 22 October 2014 19:09:37 Viktor Dukhovni wrote:
> On Wed, Oct 22, 2014 at 08:42:15PM +0200, Richard Fussenegger wrote:
> > Viktor Dukhovni already mentioned that
> > OpenSSL is actually supporting different key strengths, but for instance
> > nginx isn't exposing this setting to administrators.
> 
> For the record OpenSSL makes it possible for applications to use
> some other block cipher than aes-128-cbc, but this is not as easy
> as it sounds.  The application needs to register appropriate
> callbacks and take over key life-cycle management.  So simply using
> some other cipher-suite is not a trivial exercise, rather only once
> one is already managing key rotation via the callbacks, making the
> cipher configurable is trivial:
> 

> Perhaps I'll donate a variant of this code to OpenSSL, and then we
> can ask users to just provide algorithm name, and either a key
> lifetime for automatic in memory keys or callbacks to access
> externally managed keys.

I'd really like to see such code in OpenSSL. It would certainly help to make 
sure that the TLS 1.3 implementation meets the goals of TLS 1.3 charter.

-- 
Regards,
Hubert Kario


From nobody Thu Oct 23 07:35:33 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326F81A9041 for ; Thu, 23 Oct 2014 07:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EntNNhTNOf5P for ; Thu, 23 Oct 2014 07:35:30 -0700 (PDT)
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E70E1A9023 for ; Thu, 23 Oct 2014 07:35:30 -0700 (PDT)
Received: by mail-ig0-f171.google.com with SMTP id l13so1496217iga.10 for ; Thu, 23 Oct 2014 07:35:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:from:content-type:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=fcNInVWP+rMrviRPNQgkZA1j2XumDWYyPDj+pUF8eJc=; b=XQybO2+UAgdvN4qIPPn9osD6uFPM6U6xZHOMhcngLFj5t8hc/dKwv+oOl+N+7fyxAD TogSjcku88g83V+p5yUgp7fgfHdGGplxoiCAxm+vZHeVCFin0bDho+S2b0lWevYx+qnS IWnxULJ9derrmZn8CBLJyQr7VdQ4X/O0kG5+HUEpcbpQXqEzlDzYB+5nnjW2GceLncgt G+VJp+aap6R+mLcyu8QHCt3cOE1vn6XyA6uDP20E63iytbnAjtoo3tUJ+/hJOu2WwlvU jK7Au/q7hGaYYIkhxsplfSo2NDi93iC9RhCIoulj3tmxipZkxVw/adtV4PfoeT7ZGRED Aylg==
X-Gm-Message-State: ALoCoQkEG4KVTHyyZYJ3+kOMi1sldbnvNNIeRz757aFqKc1ZdzZ8dKVRiDhg4s0BLiBeojHiBIlM
X-Received: by 10.50.143.72 with SMTP id sc8mr12702520igb.38.1414074929661; Thu, 23 Oct 2014 07:35:29 -0700 (PDT)
Received: from [192.168.10.231] ([194.154.214.214]) by mx.google.com with ESMTPSA id y2sm1179278igl.8.2014.10.23.07.35.28 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Oct 2014 07:35:28 -0700 (PDT)
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <544606E5.2070807@fussenegger.info>  <1659862.HPNNz8lRhl@pintsize.usersys.redhat.com>  <28F97438-9D8D-40C4-9A99-AC8CF3183787@azet.org> <20141023142204.GN19158@mournblade.imrryr.org>
From: Aaron Zauner 
Content-Type: text/plain; charset=us-ascii
X-Mailer: iPhone Mail (12A405)
In-Reply-To: <20141023142204.GN19158@mournblade.imrryr.org>
Message-Id: <30A14E39-177E-4299-B49D-334AAAFAE4FA@azet.org>
Date: Thu, 23 Oct 2014 16:35:27 +0200
To: "tls@ietf.org" 
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ehc202bvxPhHSx4xP7hTLYOAcxs
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 14:35:32 -0000

> On 23.10.2014, at 16:22, Viktor Dukhovni  wrote:
> 
> On Thu, Oct 23, 2014 at 03:34:01PM +0200, Aaron Zauner wrote:
> 
>>> Right now, RFC 5077 recommends: AES-128 with a 128-bit key and
>>> HMAC-SHA256 with a 256-bit key
>> 
>> hash functions have n/2 security.
> 
> The n/2 is collision resistance.  Here the hash function is used
> in an HMAC construction.  I don't believe that n/2 applies for
> HMAC-SHA2-256.

oh. that's true.

thanks for pointing that out.

Aaron
> 
> -- 
>    Viktor.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Thu Oct 23 08:12:05 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4411AC3C5 for ; Thu, 23 Oct 2014 08:11:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.507
X-Spam-Level: 
X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQlU-PTMh5uZ for ; Thu, 23 Oct 2014 08:11:50 -0700 (PDT)
Received: from EX10ED02.qut.edu.au (ex10ed02.qut.edu.au [131.181.191.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95B51AC3A6 for ; Thu, 23 Oct 2014 08:11:46 -0700 (PDT)
Received: from EX10HT02.qut.edu.au (131.181.107.233) by EX10ED02.qut.edu.au (131.181.191.15) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 24 Oct 2014 01:11:45 +1000
Received: from EX10MB4.qut.edu.au ([169.254.6.168]) by EX10HT02.qut.edu.au ([131.181.107.233]) with mapi id 14.03.0158.001; Fri, 24 Oct 2014 01:11:44 +1000
From: Douglas Stebila 
To: Richard Fussenegger 
Thread-Topic: [TLS] Unifying tickets and sessions
Thread-Index: Ac/soXv8r4hf3UNsSPSgto+m1gTrLv//ZnwAgAALkoCAACbYgIAAeK+AgAC+5ICAATQqAIAAGWMAgAGDYYCAAA1KgIAADgKA
Date: Thu, 23 Oct 2014 15:11:43 +0000
Message-ID: 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <544606E5.2070807@fussenegger.info>  <1659862.HPNNz8lRhl@pintsize.usersys.redhat.com>  <28F97438-9D8D-40C4-9A99-AC8CF3183787@azet.org> <54490EEF.1010008@fussenegger.info>
In-Reply-To: <54490EEF.1010008@fussenegger.info>
Accept-Language: en-CA, en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [131.181.118.222]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <4687C7A5FA40364D97569A9ED4DFA99B@exchange.qut.edu.au>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sczTTSr5HAd-jS-wAWLKNY4g9_k
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 15:12:00 -0000

On Oct 23, 2014, at 4:21 PM, Richard Fussenegger =
 wrote:
>=20
> On 10/23/2014 3:34 PM, Aaron Zauner wrote:
>> 3) the appropriate reaction should be to use post-quantum crypto algorit=
hms instead of doubling the keysize for existing ones. I don't know of any =
algorithm that can be used for a protocol like TLS as of now.
>=20
> NTRU [1][2] is the only one that is said to be post-quantum [3][4] and it=
 even has a library [5] and seems to have very good performance [6][7].

There are other algorithms besides NTRU.  Here is some recent work by some =
colleagues and I on using the ring learning with errors (ring-LWE) problem =
for key exchange in TLS.

	http://eprint.iacr.org/2014/599
	links to source code: http://www.douglas.stebila.ca/research/papers/bcns14

Douglas=


From nobody Thu Oct 23 08:19:28 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C171AC3C5 for ; Thu, 23 Oct 2014 08:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level: 
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKGdaEmP_Ipv for ; Thu, 23 Oct 2014 08:19:21 -0700 (PDT)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF391AC3E4 for ; Thu, 23 Oct 2014 08:19:15 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id s9NFIuCt030658 for ; Thu, 23 Oct 2014 11:19:14 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: "'tls@ietf.org'" 
Thread-Topic: [TLS] Unifying tickets and sessions
Thread-Index: Ac/soXv8r4hf3UNsSPSgto+m1gTrLgAKJbQAAAFyS4AABNsOgAAPFcmAABfclYAAJoUkAAADLGkAADBsIYAAAalHgAAGYzXH
Date: Thu, 23 Oct 2014 15:18:41 +0000
Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC13F454E6@LLE2K10-MBX02.mitll.ad.local>
In-Reply-To: <54490EEF.1010008@fussenegger.info>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [155.34.14.22]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28,  0.0.0000 definitions=2014-10-23_06:2014-10-23,2014-10-23,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410230100
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ktaOS8xGfJBRhybXt0OfAb5n2GA
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 15:19:24 -0000

I've three concerns with NTRU:
- licensing (patents);
- (large) key size;=20
- lack of (unbroken) digital signature.

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185      =20

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  

----- Original Message -----
From: Richard Fussenegger [mailto:richard@fussenegger.info]
Sent: Thursday, October 23, 2014 09:21 AM=0A=
To: tls@ietf.org 
Subject: Re: [TLS] Unifying tickets and sessions

On 10/23/2014 3:34 PM, Aaron Zauner wrote:
> 3) the appropriate reaction should be to use post-quantum crypto algorith=
ms instead of doubling the keysize for existing ones. I don't know of any a=
lgorithm that can be used for a protocol like TLS as of now.

NTRU [1][2] is the only one that is said to be post-quantum [3][4] and=20
it even has a library [5] and seems to have very good performance [6][7].

Richard

[1] https://tools.ietf.org/html/draft-ietf-tls-ntru-00
[2] https://en.wikipedia.org/wiki/NTRUEncrypt
[3]=20
http://middleware.internet2.edu/idtrust/2009/papers/07-perlner-quantum.pdf
[4]=20
http://94.242.221.125/bookreader.php/135832/Bernstein_-_Post_Quantum_Crypto=
graphy.pdf
[5] http://www.yassl.com/yaSSL/Home.html
[6]=20
https://www.securityinnovation.com/uploads/ntru_speed_benchmark_research.pd=
f
[7] http://paper.ijcsns.org/07_book/200708/20070812.pdf


From nobody Thu Oct 23 10:20:44 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EA21AD42F for ; Thu, 23 Oct 2014 10:20:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS81PWYauQ59 for ; Thu, 23 Oct 2014 10:20:38 -0700 (PDT)
Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807191AD432 for ; Thu, 23 Oct 2014 10:20:38 -0700 (PDT)
Received: by mail-yh0-f47.google.com with SMTP id c41so1593260yho.20 for ; Thu, 23 Oct 2014 10:20:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=ZDT5MC8oCzmJlqo3quoCHmZBTmCmwpjXdzyADqGmLEA=; b=NMnhMMJVQZjEb7xEVnfOyPoJjladgRAywc8ZR7dr/hrlcLTeeQmaKKD0HPZbVCujxF twGH2UTQEBR49vpjEcddoEcjFdDI8GHApotD6Xg8WCrO1k1qhX5gPGhPDdXBVdmoxtkC 7jDhx/q9p/vo3diDjsO6G59SBAlXk/erOIIN1U7h679m4P/b3u4phdEmXu8yWORBCLmY tlxwxVEZV55vDYW1PZg084TFFKnvyHYxbw/swefQ2Fzs7LF6VEjWDLrGCRlG6kJrULQa 3ulU0sBXlsQivOJXQIwTZHUXpgEXlweQE936gMMYehsXaW9Kk7Tp1mFTdjdxkObopyOZ rz1Q==
X-Gm-Message-State: ALoCoQldgCi8LaZcjM0oDeVtjnbkxobZtYUELu/x4t7PXk33uzdW7NJNNkeIeYg823TQNIKdukuN
X-Received: by 10.170.152.135 with SMTP id t129mr542475ykc.66.1414084837764; Thu, 23 Oct 2014 10:20:37 -0700 (PDT)
Received: from zbox.pahtak.org (c-68-48-196-126.hsd1.md.comcast.net. [68.48.196.126]) by mx.google.com with ESMTPSA id c3sm2014422qga.47.2014.10.23.10.20.36 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Oct 2014 10:20:36 -0700 (PDT)
Received: from [128.220.247.217] (unknown [128.220.247.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id DC0C9AC28D6 for ; Thu, 23 Oct 2014 13:20:34 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Stephen Checkoway 
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64F14@USMBX1.msg.corp.akamai.com>
Date: Thu, 23 Oct 2014 13:20:29 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <77CCA3E5-C42C-4A81-A443-8C20A842EF61@pahtak.org>
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <20141023060003.GM19158@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64F14@USMBX1.msg.corp.akamai.com>
To: "tls@ietf.org" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gUeF2Ztm0L4tMDA1tttOVknKWAc
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 17:20:40 -0000

On Oct 23, 2014, at 3:08 AM, Salz, Rich  wrote:

>=20
>=20
>> If excluding opportunistic security is too painful, and it is better =
for the draft
>> to have an undiluted message than a nuanced one based on more =
pragmatic
>> considerations, fine, so be it, make it pure.
>> We'll muddle along violating it as necessary.
>=20
> I believe this is the consensus.

+1

--=20
Stephen Checkoway






From nobody Thu Oct 23 10:22:18 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79D61AD44E for ; Thu, 23 Oct 2014 10:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHumysRQw9oh for ; Thu, 23 Oct 2014 10:22:08 -0700 (PDT)
Received: from mx206.easyname.com (mx206.easyname.com [212.232.25.162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A674D1AD44C for ; Thu, 23 Oct 2014 10:21:37 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XhM4q-0007ES-KO for tls@ietf.org; Thu, 23 Oct 2014 19:21:36 +0200
Message-ID: <54493904.7010807@fussenegger.info>
Date: Thu, 23 Oct 2014 19:21:08 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com>
In-Reply-To: <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090406040400030006060907"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rBDAP4EzUS_x8GCHi5box_r9mVo
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 17:22:12 -0000

This is a cryptographically signed message in MIME format.

--------------ms090406040400030006060907
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

On 10/23/2014 4:03 PM, Hubert Kario wrote:
> While it may negotiate AES-256 (because it wants to interoperate with=20
> clients that are configured to not to present weaker ciphers), doesn't =

> mean that it as a whole is configured to the 256 bit level of=20
> security. With TLS1.2 it may sign the (EC)DHE parameters using SHA-1,=20
> it may use RSA key exchange using only 2048 bit keys, it may be just a =

> local proxy server that is hard coded to connect using AES-128 with=20
> the backed servers over open Internet. Yes, server should encrypt the=20
> tickets with as strong algorithm as its most secure cipher, but there=20
> are many situations where it's not necessary. "MUST" is certainly not=20
> applicable.=20

Those are good and valid arguments for a RECOMMENDED regarding session=20
ticket/token key algorithms or simply dropping one word and uppercasing=20
another does the trick (?):

https://tools.ietf.org/html/rfc5077#section-5.5
>    o  The keys and cryptographic protection algorithms should be at
>       least 128 bits in strength.  Some ciphersuites and applications
> -     may require cryptographic protection greater than 128 bits in
> +     REQUIRE cryptographic protection greater than 128 bits in
>       strength.

But the MUST regarding key rotation, key discarding, and key count hard=20
limits is still appropriate in my opinion because PFS is a MUST in TLS=20
1.3 (unless this has changed and I didn't read about it).

To answer Rich Salz's initial question, if we'd have 24h encryption and=20
72h decryption on the server-side (as I proposed and nobody said=20
anything pro or contra) the MUST NOT for ticket/token lifetime would=20
become 48h.

server-side key:
          24h enc
|------------------------|         24h denc
                          |------------------------|        24h denc
|------------------------|
client:
                                                 48h
|-------------------------------------------------|

I personally think that this illustrates the rationale behind my timings =

(on which I'm not insisting, just an idea I share with you and want to=20
discuss). If the client receives a ticket/token just before the first=20
rotation, it can revisit within 48h and the ticket/token is still valid=20
if three keys are in use (and I wouldn't allow for more, otherwise=20
there's a hole in the RFC that allows people to keep keys until their=20
storage runs out). Of course there might be some edge cases where the=20
ticket/token is still valid according to the lifetime but with this big=20
window it shouldn't matter anymore.

Richard


--------------ms090406040400030006060907
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjMxNzIxMDhaMCMGCSqGSIb3DQEJBDEWBBThEtL/HlvcRW6/9zzjQIruOybtODBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEASkYlpHNvULOSGDC6KbqxDK55nI69
P1bvhy6NVOFfH5FbufAtMgl2vL7IyYrSju2mb+oLB1w1CuTFbw6w9vdJO91/rUDHqDkB60AY
yoArPT301DW+X3vnHvlEctSxiXlI0GIAqNOjLvmdE+ahN2Ce1BJ26AeTZvKlLbPMzY4I7qnM
UXLk88mbGArpxuKrWfRSS6oyzFJ+N01FKrRO2Zs39Ih4TBlO6FP7P09T0g9pGxqtKUMyfBc4
ZEJH6skOtEFfzABX3Mm1KlFGNOJNKn2mWKU97ZA2QvPR+KWBbNL7dpVySb0Z1bUAsdC40DW1
zFi8SqIFCgo+Spj9p2OW0BgsxgAAAAAAAA==
--------------ms090406040400030006060907--


From nobody Thu Oct 23 10:31:47 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3DC1ACD9E for ; Thu, 23 Oct 2014 10:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sJ0Sy_Yf45U for ; Thu, 23 Oct 2014 10:31:43 -0700 (PDT)
Received: from mx203.easyname.com (mx203.easyname.com [212.232.28.124]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029E11A8A48 for ; Thu, 23 Oct 2014 10:31:43 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XhMEZ-0000ga-JZ for tls@ietf.org; Thu, 23 Oct 2014 19:31:41 +0200
Message-ID: <54493B60.3070706@fussenegger.info>
Date: Thu, 23 Oct 2014 19:31:12 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info>
In-Reply-To: <54493904.7010807@fussenegger.info>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050401010004060806090904"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lsAcQLnxvL7ZIKgGGnoyo4UFrYw
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 17:31:45 -0000

This is a cryptographically signed message in MIME format.

--------------ms050401010004060806090904
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable


On 10/23/2014 7:21 PM, Richard Fussenegger wrote:
> server-side key:
>          24h enc
> |------------------------|         24h denc
>                          |------------------------|        24h denc
> |------------------------|
> client:
>                                                 48h
> |-------------------------------------------------|

The drawing got messed up, see here: http://pastebin.com/1iAatbWm

Richard


--------------ms050401010004060806090904
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjMxNzMxMTJaMCMGCSqGSIb3DQEJBDEWBBTSS8FdZwiu0N+ydbTJqU89tYnJnjBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEAVtto6VfLBmXy866ejwHdoIVtz2eD
CibWH+O5B5WjofC09L/tm36GlAw6mrVJ57LFOCD4NL7aKT235Af1GU2zyFIIOo1Gvrz3su5+
+mJOEQzC7QdiMwXYnXXPB/DIOCyOBqme+Xe8xIGJ9w+7/fsfpDL6YmtoIG+OOJARLBUR/ycm
WB7T2620sak222mxVLBDJ4/ZPAINddkPVORpRygavlLonnKWYBQorUNRB7LLr7vJLzlO6DqV
Mk6CAhY9zzE+hmX5Q+Zmk4RkWmm+/0/r9xUeGCxzUwc3xrqTIL9CgFJqDD5/J/v3rNj6+yxi
/RWrbykPwc8z6ItIucUdzOWojwAAAAAAAA==
--------------ms050401010004060806090904--


From nobody Thu Oct 23 10:45:43 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484131A8AD2 for ; Thu, 23 Oct 2014 10:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6bVz4ln8AjM for ; Thu, 23 Oct 2014 10:45:40 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32ADD1A8AA9 for ; Thu, 23 Oct 2014 10:45:40 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3E46F2AB2BB; Thu, 23 Oct 2014 17:45:38 +0000 (UTC)
Date: Thu, 23 Oct 2014 17:45:38 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141023174537.GW19158@mournblade.imrryr.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54493904.7010807@fussenegger.info>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eexJvHVaFboajwXmpn5Q-fo1ySU
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 17:45:42 -0000

On Thu, Oct 23, 2014 at 07:21:08PM +0200, Richard Fussenegger wrote:

> To answer Rich Salz's initial question, if we'd have 24h encryption and 72h
> decryption on the server-side (as I proposed and nobody said anything pro or
> contra)

There is another variable at play here, in many implementations
there is a potentially independent upper bound on the lifetime of
resumed sessions, whether stateful or otherwise.

In Postfix (which is based on OpenSSL) I arrange for the session
lifetime limit to be double the key rotation interval.  Say that
is 1 hour, then the session lifetime is set to 2 hours.  Each key
is used to encrypt new traffic for an hour, then it becomes the
cached decryption key and a new encryption key is used.

There are only ever two keys sets in memory: the current encryption
key set and prior encryption (additional decryption) keyset.  I
say key set because we need an encryption key and an HMAC key and
both are rotated together, with these is associated a 16 octent id
(could be a counter or simply random).

> the MUST NOT for ticket/token lifetime would become 48h.
> 
> server-side key:
>          24h enc
> |------------------------|         24h denc
>                          |------------------------|        24h denc
> |------------------------|
> client:
>                                                 48h
> |-------------------------------------------------|

The set of sessions encrypted under a single key is still 24 hours,
but the length of time for which the key is exposed on the server
is 48 hours.  And indeed a session is valid for anywhere between
24 and 48 hours depending on when in the encryption key's lifetime
it got created.

> If the client receives a ticket/token just before the first rotation, it can
> revisit within 48h and the ticket/token is still valid if three keys are in
> use.

Actually two key sets are sufficient.  There is no need for a third
key set.  Take a look at postfix/src/tls/tls_scache.c the relevant
functions are tls_scache_key() and tls_scache_key_rotate().

This is used in postfix/src/tls/tls_mgr.c tls_mgr_key().

    https://github.com/vdukhovni/postfix

-- 
	Viktor.


From nobody Thu Oct 23 11:18:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6341A90FC for ; Thu, 23 Oct 2014 11:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQw82FTtSGKH for ; Thu, 23 Oct 2014 11:18:31 -0700 (PDT)
Received: from mx204.easyname.com (mx204.easyname.com [212.232.28.125]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C021ACE47 for ; Thu, 23 Oct 2014 11:18:02 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XhMxS-000648-0E for tls@ietf.org; Thu, 23 Oct 2014 20:18:00 +0200
Message-ID: <5449463D.7080904@fussenegger.info>
Date: Thu, 23 Oct 2014 20:17:33 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <20141023174537.GW19158@mournblade.imrryr.org>
In-Reply-To: <20141023174537.GW19158@mournblade.imrryr.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060705090600070209080101"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/179Mn7DP5hN6eWrilkPokRe1cro
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 18:18:34 -0000

This is a cryptographically signed message in MIME format.

--------------ms060705090600070209080101
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 10/23/2014 7:45 PM, Viktor Dukhovni wrote:
> There are only ever two keys sets in memory: the current encryption
> key set and prior encryption (additional decryption) keyset.  I
> say key set because we need an encryption key and an HMAC key and
> both are rotated together, with these is associated a 16 octent id
> (could be a counter or simply random).

I like the wording 'key set' and it's actually what I was referring to=20
too. The key sets that are generated in my script for nginx are simply=20
48 B of random data (key_name, iv, key, mac):

https://github.com/Fleshgrinder/nginx-session-ticket-key-rotation/blob/ma=
ster/config.sh#L420-L457
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket=
_key

> Actually two key sets are sufficient.  There is no need for a third
> key set.  Take a look at postfix/src/tls/tls_scache.c the relevant
> functions are tls_scache_key() and tls_scache_key_rotate().
>
> This is used in postfix/src/tls/tls_mgr.c tls_mgr_key().
>
>      https://github.com/vdukhovni/postfix

I adopted the three key idea from Twitter[1] and yes two key sets are=20
sufficient. I thought that Twitters rational behind the three keys was=20
to extend the lifetime of tickets on the client side (as in my drawing=20
http://pastebin.com/1iAatbWm) without extending the lifetime of the=20
encryption key. Of course I could be terribly wrong here but Jacob=20
Hoffman-Andrews for sure had some idea behind this rational.

If the upper limit is said to be two tickets, Twitter has to adopt there =

system. Since we already have a prominent example that uses three=20
tickets, its imho a good idea to let them continue doing so. Note that=20
your approach would still be perfectly valid because you're below the=20
hard limit of three tickets. Hence if one decides to use a single key=20
and simply send it to nirvana after 24h then that's okay as well. The=20
goal is that we don't botch PFS and not to dictate how keys are implement=
ed.

That said, I have no problem with two keys especially if there is an=20
argument against using three keys in regards to security. Maybe I should =

ask Jacob Hoffman-Andrews from Twitter why they are using three keys?

Richard

[1] https://blog.twitter.com/2013/forward-secrecy-at-twitter


--------------ms060705090600070209080101
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjMxODE3MzNaMCMGCSqGSIb3DQEJBDEWBBSo+yaFz5do4Q2mz396bVe8q/TiaTBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEADAQE4adeMnrhbh7hOT3jzQqG92d8
TQg5Zz/5YPmaPFH7ArCi7SAxhMqdjJxAIcys7A3wY+x5nSWX/9/cp6WHb3bV2bNJstCutKzd
frhSIFssZXKZhfnhzvH0DrNQqe2A35PpMYjR2me8KlmBYRe7gD2Kg5uF8gEe/9GBbQs23WhR
iEuUbodSfnt89SlLXgOyagAfHdzaQffFi8z8Iy08uVPZUFkAR/VfLkreBcHsybDYrCS5IY0d
Vf4AJCzOcjjHPUluF44qb5GH5r5h+O7BRSasJPpBQzqKn2WnBkzP6T8v7D2yKZePtQvwgkcO
uujEIf1NsWTdjtlY+1AVq2KXyAAAAAAAAA==
--------------ms060705090600070209080101--


From nobody Thu Oct 23 11:21:39 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8025F1A8ACC for ; Thu, 23 Oct 2014 11:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.034
X-Spam-Level: 
X-Spam-Status: No, score=0.034 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYK9prKFP0Us for ; Thu, 23 Oct 2014 11:21:36 -0700 (PDT)
Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E4A6A1A87BB for ; Thu, 23 Oct 2014 11:21:36 -0700 (PDT)
Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 7D0A95080BB; Thu, 23 Oct 2014 11:21:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=jVRi7am3rRXrqvJ1/mXBYbzmQP4=; b=aYgl79jdn7q tUANMvLneDP6lO79OfCEtqKtTBdxww9WmS2tOMpyCHheyRw6+fmFNkoeASWWk8cb iHYar2ujNqnvvV1Wd/jRIx5CY0Bpz1P7qo7DtzDtIlR2E02jYINVUwBy8dy2Ujj1 7+7FT/UWQ7vDUfMewqOIauUo8pNInvy8=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id 26FB4508064; Thu, 23 Oct 2014 11:21:35 -0700 (PDT)
Date: Thu, 23 Oct 2014 13:21:31 -0500
From: Nico Williams 
To: Manuel =?iso-8859-1?Q?P=E9gouri=E9-Gonnard?= 
Message-ID: <20141023182129.GA3752@localhost>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org>  <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE4@USMBX1.msg.corp.akamai.com> <54483D4C.9060809@polarssl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <54483D4C.9060809@polarssl.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TFEeoxcVXVqOv_t8UTfsWbpVjTE
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 18:21:37 -0000

On Thu, Oct 23, 2014 at 01:27:08AM +0200, Manuel P=E9gouri=E9-Gonnard wro=
te:
> I don't think this is correct. Once the server emits the ticket (if we'=
re
> speaking about a ticket that contains session state including the MS), =
it's out
> there in the clear* for an attacker to play with. That the client choos=
es to
> ignore the ticket doesn't change that fact.
>
> [...]
>
> * For TLS 1.2 I mean. For 1.3 that might be different.

The ticket has to always be sent in the clear during resumption,
otherwise there's no point in having session resumption with tickets :)

The key material to super-protect a ticket would have to come from
somewhere: if not the ticket, then from a slower key exchange... that
session resumption means to avoid.

Nico
--=20


From nobody Thu Oct 23 11:36:43 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3061E1A1A38 for ; Thu, 23 Oct 2014 11:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaxU0L8bF-Tj for ; Thu, 23 Oct 2014 11:36:39 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D6D1A1A31 for ; Thu, 23 Oct 2014 11:36:39 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 950752AB2BB; Thu, 23 Oct 2014 18:36:37 +0000 (UTC)
Date: Thu, 23 Oct 2014 18:36:37 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141023183637.GX19158@mournblade.imrryr.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <20141023174537.GW19158@mournblade.imrryr.org> <5449463D.7080904@fussenegger.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5449463D.7080904@fussenegger.info>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mAD2jKBVXN6oj6h55Kwa5XM4884
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 18:36:41 -0000

On Thu, Oct 23, 2014 at 08:17:33PM +0200, Richard Fussenegger wrote:

> I like the wording 'key set' and it's actually what I was referring to too.
> The key sets that are generated in my script for nginx are simply 48 B of
> random data (key_name, iv, key, mac):

The iv should not be part of the persistent key set.  It is a new
random value for each client, returned to the server as part of
the ticket.  The key set is just (name, key, mac).  The in memory
version in Postfix also holds a timeout:

    typedef struct TLS_TICKET_KEY {
	unsigned char name[TLS_TICKET_NAMELEN];
	unsigned char bits[TLS_TICKET_KEYLEN];
	unsigned char hmac[TLS_TICKET_MACLEN];
	time_t  tout;
    } TLS_TICKET_KEY;

> I adopted the three key idea from Twitter[1] and yes two key sets are
> sufficient. I thought that Twitters rationale behind the three keys was to
> extend the lifetime of tickets on the client side (as in my drawing
> http://pastebin.com/1iAatbWm) without extending the lifetime of the
> encryption key. Of course I could be terribly wrong here but Jacob
> Hoffman-Andrews for sure had some idea behind this rationale.

There is no particular advantage to three keys,  it just means that
the range of session lifetimes is between 2T and 3T, rather than
between T and 2T, if that's compelling (less variance) go for it.

> If the upper limit is said to be two tickets, Twitter has to adopt there
> system. Since we already have a prominent example that uses three tickets,
> its imho a good idea to let them continue doing so. Note that your approach
> would still be perfectly valid because you're below the hard limit of three
> tickets.

I think you mean "key sets" not "tickets", and still I have no idea
what the above is talking about.  There is no "hard limit".  One
can use 24 keysets each good for encryption for 1 hour and decryption
for 23 after that.  It just means more data to shuffle in memory.
I used 2 key sets because it was simpler.

> That said, I have no problem with two keys especially if there is an
> argument against using three keys in regards to security. Maybe I should ask
> Jacob Hoffman-Andrews from Twitter why they are using three keys?

The number of key sets is irrelevant, all that matters is how long
each one is retained.  Postfix defaults to 2 hours (1 hour encrypt
and 1 hour decrypt).  With N keysets, you'd have (T encrypt, (N-1)*T
decrypt).

-- 
	Viktor.


From nobody Thu Oct 23 11:56:02 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C441A1A13 for ; Thu, 23 Oct 2014 11:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP6-DpCwrLea for ; Thu, 23 Oct 2014 11:55:58 -0700 (PDT)
Received: from mx204.easyname.com (mx204.easyname.com [212.232.28.125]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E921A0AF8 for ; Thu, 23 Oct 2014 11:55:58 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XhNYA-0001wo-Og for tls@ietf.org; Thu, 23 Oct 2014 20:55:57 +0200
Message-ID: <54494F20.7060002@fussenegger.info>
Date: Thu, 23 Oct 2014 20:55:28 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <20141023174537.GW19158@mournblade.imrryr.org> <5449463D.7080904@fussenegger.info> <20141023183637.GX19158@mournblade.imrryr.org>
In-Reply-To: <20141023183637.GX19158@mournblade.imrryr.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040806080800050906090402"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BPp3T7bRjQz-LfdMPP-YyCyPcfY
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 18:56:01 -0000

This is a cryptographically signed message in MIME format.

--------------ms040806080800050906090402
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 10/23/2014 8:36 PM, Viktor Dukhovni wrote:
> The iv should not be part of the persistent key set.  It is a new
> random value for each client, returned to the server as part of
> the ticket.  The key set is just (name, key, mac).  The in memory
> version in Postfix also holds a timeout:
>
>      typedef struct TLS_TICKET_KEY {
> 	unsigned char name[TLS_TICKET_NAMELEN];
> 	unsigned char bits[TLS_TICKET_KEYLEN];
> 	unsigned char hmac[TLS_TICKET_MACLEN];
> 	time_t  tout;
>      } TLS_TICKET_KEY;

I didn't implement it but nginx requires 48 B otherwise it's not working =

and that's definitely more than only key and mac. Maybe the complete=20
thing is broken in nginx then? [1]

> I think you mean "key sets" not "tickets", and still I have no idea
> what the above is talking about.  There is no "hard limit".  One
> can use 24 keysets each good for encryption for 1 hour and decryption
> for 23 after that.  It just means more data to shuffle in memory.
> I used 2 key sets because it was simpler.

Absolutely, I meant 'key sets' not tickets. Well, I proposed that three=20
key sets could become a hard limit and was referring to that proposition =

[2] because: [3]

> otherwise there's a hole in the RFC that allows people to keep keys=20
> until their storage runs out

You may swap 'storage' with 'RAM' in that sentence, doesn't matter.

Richard

[1]=20
https://github.com/nginx/nginx/blob/bb8c0683da773566e09797ef8a4ee00ad1e0f=
956/src/event/ngx_event_openssl.c#L2628-L2739
[2] http://www.ietf.org/mail-archive/web/tls/current/msg14168.html
[3] http://www.ietf.org/mail-archive/web/tls/current/msg14188.html


--------------ms040806080800050906090402
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjMxODU1MjhaMCMGCSqGSIb3DQEJBDEWBBTA4d6JkfuAA5AIv3A14R/83SXutTBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEAufPzg3xU+ZQHrFFdEzKjm7UUEdzW
CyEeudoI8TXgOTUsUsCLOKFnjn0YL1mXcYsZdZyVXUPL9ByaWjmNIHJS0rdKlO4Z2FslZwm5
LF3xWRUs9ot+Nf385P74mp7E0x2HbYMZMx8cy/i3a8GJubveOsfnGJzBh2wdtUsdGKwTOUE5
sNg8PYxhJR8cHHdhl7SroiuZrigS3LtK29/C7zT12wGsJIomPV8ClNdpfLnxQmv/JQ+JOEOo
lt1FcoqdZsfq1LXwu2cj+DizntX0KVc5pnfNdM7rBybqT8HWCRr4zVlhhAVH2bpRjTKoXsA5
y9TLcYqj3+W/pz5duQOh4QhqhAAAAAAAAA==
--------------ms040806080800050906090402--


From nobody Thu Oct 23 12:36:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528AB1ACFD2 for ; Thu, 23 Oct 2014 12:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr85kue89j6p for ; Thu, 23 Oct 2014 12:36:08 -0700 (PDT)
Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32B71ACFC8 for ; Thu, 23 Oct 2014 12:36:08 -0700 (PDT)
Received: by mail-qa0-f52.google.com with SMTP id v10so32486qac.11 for ; Thu, 23 Oct 2014 12:36:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=falVe+BJIetsAFECGDyia+JnCoPxlwqTrgt2NafI6fA=; b=aEsI53k/Sebi+AcKgOXegsKxlf4Mfs+cTdnkcl0kTg9UkZ1HqgfQ8kNtdMCscuz2Oh V5a8rSBBuqqIMXgWUj6QEK7u+SPnM9Ba4Upbek9XA3kVGy3lfpehKusV6q80YEE1aPYJ BZzTcaerQQ0u3uheaZhbkHGnfVM+1B3WDebwEgA/rC2zsunfeoYgCkUHY/ZZB3sVS+PK 4RlaiySwYd7Fi5atvk5z39jXVUSFfoIHfgUAKlCoyXgXnE+1cr25a1nBdrgz7OZ+dALl NkZnIYTEQZrXfoS3VG213GHy62s3xXhisl05uWU7wa4Viq6FN5q9+wKH295d6w65mfgN 6ivA==
X-Gm-Message-State: ALoCoQkLVN6gvTANSQNERZTZdjn/YopR0Hsu7I2OI0hoLgqgKyQPFw9WXXaEd7KY1Kx0mVGNYhpD
X-Received: by 10.170.134.196 with SMTP id a187mr883826ykc.53.1414092967867; Thu, 23 Oct 2014 12:36:07 -0700 (PDT)
Received: from zbox.pahtak.org (c-68-48-196-126.hsd1.md.comcast.net. [68.48.196.126]) by mx.google.com with ESMTPSA id w9sm2333557qaw.9.2014.10.23.12.36.06 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Oct 2014 12:36:06 -0700 (PDT)
Received: from [128.220.247.217] (unknown [128.220.247.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id D01A9AC28D6 for ; Thu, 23 Oct 2014 15:36:04 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Stephen Checkoway 
In-Reply-To: <20141023183637.GX19158@mournblade.imrryr.org>
Date: Thu, 23 Oct 2014 15:35:59 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <03546F3D-816C-481A-A577-9797855A9DED@pahtak.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <20141023174537.GW19158@mournblade.imrryr.org> <5449463D.7080904@fussenegger.info> <20141023183637.GX19158@mournblade.imrryr.org>
To: tls@ietf.org
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jd9vSnFm7z16PZZ1l87lABGgzZ0
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 19:36:10 -0000

On Oct 23, 2014, at 2:36 PM, Viktor Dukhovni  =
wrote:

> The number of key sets is irrelevant, all that matters is how long
> each one is retained.  Postfix defaults to 2 hours (1 hour encrypt
> and 1 hour decrypt).  With N keysets, you'd have (T encrypt, (N-1)*T
> decrypt).

This seems perfectly reasonable (both for general N and for specific N =3D=
 2 or N =3D 3). But does it make any difference from a protocol =
perspective? The only way a client could tell if a server is doing =
something wrong is if the client knows the upper limit on the ticket's =
validity  NT and sends a ticket after that time which the server =
accepts.

I'm probably missing something but it seems like there's no real way to =
detect if the server has followed any particular policy for a ticket so =
the details (such as key rotation and symmetric algorithm strength) =
should be left entirely up to the server. (Or resumption should be =
dropped from 1.3.)

Giving guidance seems reasonable. Setting unenforceable limits does not.

--=20
Stephen Checkoway






From nobody Thu Oct 23 12:54:16 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886391ACFFE for ; Thu, 23 Oct 2014 12:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7d8d1zI0o9A for ; Thu, 23 Oct 2014 12:54:03 -0700 (PDT)
Received: from mx205.easyname.com (mx205.easyname.com [212.232.28.126]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0A41ACEBA for ; Thu, 23 Oct 2014 12:54:03 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XhOSN-0008NX-JM for tls@ietf.org; Thu, 23 Oct 2014 21:54:01 +0200
Message-ID: <54495CBF.6040809@fussenegger.info>
Date: Thu, 23 Oct 2014 21:53:35 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <20141023174537.GW19158@mournblade.imrryr.org> <5449463D.7080904@fussenegger.info> <20141023183637.GX19158@mournblade.imrryr.org> <03546F3D-816C-481A-A577-9797855A9DED@pahtak.org>
In-Reply-To: <03546F3D-816C-481A-A577-9797855A9DED@pahtak.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000903060004070604050700"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hZF0Do70A5eKCUWQAIBpIDcykNs
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 19:54:09 -0000

This is a cryptographically signed message in MIME format.

--------------ms000903060004070604050700
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 10/23/2014 9:35 PM, Stephen Checkoway wrote:
> This seems perfectly reasonable (both for general N and for specific N =
=3D 2 or N =3D 3). But does it make any difference from a protocol perspe=
ctive? The only way a client could tell if a server is doing something wr=
ong is if the client knows the upper limit on the ticket's validity  NT a=
nd sends a ticket after that time which the server accepts.
>
> I'm probably missing something but it seems like there's no real way to=
 detect if the server has followed any particular policy for a ticket so =
the details (such as key rotation and symmetric algorithm strength) shoul=
d be left entirely up to the server. (Or resumption should be dropped fro=
m 1.3.)
>
> Giving guidance seems reasonable. Setting unenforceable limits does not=
=2E

Some parties think that only giving recommendations isn't enough=20
(example quoted below), so why not give some rules then? Of course=20
there's no way for a client to validate anything, but at least people=20
can perform code reviews to check open or their own closed source=20
projects to see if they are implemented correctly according to the RFC.

> The RFC doesn=E2=80=99t describe how key management should be performed=
 and=20
> merely emits recommendations. This has been found to be problematic in =

> OpenSSL=E2=80=99s case [=E2=80=A6]
> =E2=80=94Florent Daigniere: =E2=80=9CTLS =E2=80=9CSecrets=E2=80=9D=E2=80=
=9D, p. 7, online:=20
> https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-WP.pdf

I know, I'm using that reference too much, still =E2=80=A6

Richard


--------------ms000903060004070604050700
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjMxOTUzMzVaMCMGCSqGSIb3DQEJBDEWBBRn9gLziZm8hyXEpDBs90sCnpSNTDBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEAqbsKIYmQ3mjhuxfHWDHk4Pe6o/yd
+6UMcsAJLMsu4moiGlTkUfYlMnNPX7FwlebDekPdJ5FgJKuJSLIHdXNjHhT1ycg2+9g5UZpG
wFOVdbqSA9fhjDko9S/SkGXaUNRnyygO+UD8aCxDSo2XDeR5qRvHeKqSwBphiwNV9dfgI7rI
J22QOAOqOOTK7KPdiRCaNnSdDT1dVeM3VSDklyvs4f6xO3T9cR0LqweZemncyWQJKwvA1pO4
C36ro2bRutoxT8uaAgvzDYKVj1UfprXf2gB07EsQvhY0xTUAnZdtDebUxUMTCMBxpVZfkFuW
tq9+TK+FJyDIUm+64xENisNf+AAAAAAAAA==
--------------ms000903060004070604050700--


From nobody Thu Oct 23 13:01:40 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7FD1AD04C for ; Thu, 23 Oct 2014 13:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2KWxYWvcREA for ; Thu, 23 Oct 2014 13:01:35 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66CC31AD046 for ; Thu, 23 Oct 2014 13:01:35 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5B10D2AB2B5; Thu, 23 Oct 2014 20:01:34 +0000 (UTC)
Date: Thu, 23 Oct 2014 20:01:34 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141023200134.GY19158@mournblade.imrryr.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <20141023174537.GW19158@mournblade.imrryr.org> <5449463D.7080904@fussenegger.info> <20141023183637.GX19158@mournblade.imrryr.org> <03546F3D-816C-481A-A577-9797855A9DED@pahtak.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <03546F3D-816C-481A-A577-9797855A9DED@pahtak.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8eEITLrQiEzHpeGb0Cm5I_KvTe4
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 20:01:37 -0000

On Thu, Oct 23, 2014 at 03:35:59PM -0400, Stephen Checkoway wrote:

> On Oct 23, 2014, at 2:36 PM, Viktor Dukhovni  wrote:
> 
> > The number of key sets is irrelevant, all that matters is how long
> > each one is retained.  Postfix defaults to 2 hours (1 hour encrypt
> > and 1 hour decrypt).  With N keysets, you'd have (T encrypt, (N-1)*T
> > decrypt).
> 
> This seems perfectly reasonable (both for general N and for
> specific N = 2 or N = 3). But does it make any difference from a
> protocol perspective? The only way a client could tell if a server
> is doing something wrong is if the client knows the upper limit on
> the ticket's validity  NT and sends a ticket after that time which
> the server accepts.

OpenSSL at least enforces the N*T time-limit on sessions, and in
case would not be able to decrypt a session ticket whose key has
been discarded.  So Postfix sets 2*T as the session lifetime, and
as a result if a session ticket is decrypted the session will not
be accepted.


> I'm probably missing something but it seems like there's no real way to
> detect if the server has followed any particular policy for a ticket so
> the details (such as key rotation and symmetric algorithm strength) should
> be left entirely up to the server. (Or resumption should be dropped from
> 1.3.)

Indeed the client has no way to know whether the server has erased
previous session ticket keys.

> Giving guidance seems reasonable. Setting unenforceable limits does not.

I have no opinion on whether any limit needs to be "enforceable".
Key rotation needs to happen, but the client has no way to verify,
that's just life.

-- 
	Viktor.


From nobody Thu Oct 23 13:07:08 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455CB1ACEAD for ; Thu, 23 Oct 2014 13:07:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ko1qP5fp8-iM for ; Thu, 23 Oct 2014 13:07:04 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2E31A0861 for ; Thu, 23 Oct 2014 13:07:04 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9F4592AB2B5; Thu, 23 Oct 2014 20:07:02 +0000 (UTC)
Date: Thu, 23 Oct 2014 20:07:02 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141023200702.GZ19158@mournblade.imrryr.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <20141023174537.GW19158@mournblade.imrryr.org> <5449463D.7080904@fussenegger.info> <20141023183637.GX19158@mournblade.imrryr.org> <54494F20.7060002@fussenegger.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54494F20.7060002@fussenegger.info>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F2DzTe8Hi2qBt2ZpI0q2H8h4LIw
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 20:07:06 -0000

On Thu, Oct 23, 2014 at 08:55:28PM +0200, Richard Fussenegger wrote:

> On 10/23/2014 8:36 PM, Viktor Dukhovni wrote:
> >The iv should not be part of the persistent key set.  It is a new
> >random value for each client, returned to the server as part of
> >the ticket.  The key set is just (name, key, mac).  The in memory
> >version in Postfix also holds a timeout:
> >
> >     typedef struct TLS_TICKET_KEY {
> >	unsigned char name[TLS_TICKET_NAMELEN];
> >	unsigned char bits[TLS_TICKET_KEYLEN];
> >	unsigned char hmac[TLS_TICKET_MACLEN];
> >	time_t  tout;
> >     } TLS_TICKET_KEY;
> 
> I didn't implement it but nginx requires 48 B otherwise it's not working and
> that's definitely more than only key and mac. Maybe the complete thing is
> broken in nginx then? [1]

The reason nginx has 48 bytes is that it stores a 16 byte name,
followed by a 16-byte (AES-128) key and a 16-byte HMAC secret.

Postfix uses 16 + 32 + 32 = 80, because the key is for AES-256 and
the HMAC key for SHA2-256 is also chosen to be 256 bits.

The nginx implementation can be "strengthened" from AES-128 to
AES-256 just in case someone wants to burn a few million years of
a 4GW power plant to brute force a session ticket on a classical
computer, or future quantum computers can search a 2^128 key space
in 2^64 time.

-- 
	Viktor.


From nobody Thu Oct 23 13:49:58 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246EC1AD445 for ; Thu, 23 Oct 2014 13:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQjOuBq4Hks3 for ; Thu, 23 Oct 2014 13:49:54 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id B68F81AD430 for ; Thu, 23 Oct 2014 13:49:54 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DC13D475D8; Thu, 23 Oct 2014 20:49:53 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id D049F475D4; Thu, 23 Oct 2014 20:49:53 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id CCC458004E; Thu, 23 Oct 2014 20:49:53 +0000 (GMT)
Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 23 Oct 2014 16:49:53 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 23 Oct 2014 16:49:52 -0400
From: "Salz, Rich" 
To: Stephen Farrell , "tls@ietf.org" 
Date: Thu, 23 Oct 2014 16:49:51 -0400
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: Ac/uTJLy+zY7fKesT6G9N8RBc5B1XgAtPy8w
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com>
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie>
In-Reply-To: <544837FD.202@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GQ25lu1_KrSKecdeJF6479C5Rc0
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 20:49:56 -0000

> I think there is a significant difference between the security (in partic=
ular
> confidentiality) one gets with good and dodgy algorithms which is suffici=
ent
> to argue that the OS design pattern is inappropriate to use with such dod=
gy
> algs.

I'm having trouble parsing things.  You don't mean "both good and dodgy," b=
ut rather "good compared with dodgy" or "good contrasted with dodgy"

Sorry, you IE folks are just too good with words for a poor old yank like m=
e :)=20

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Thu Oct 23 15:39:33 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FC21A872C for ; Thu, 23 Oct 2014 15:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uYU-_M-fsIe for ; Thu, 23 Oct 2014 15:39:25 -0700 (PDT)
Received: from mx201.easyname.com (mx201.easyname.com [212.232.28.122]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030801A8739 for ; Thu, 23 Oct 2014 15:39:24 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XhR2M-0008Lb-T4 for tls@ietf.org; Fri, 24 Oct 2014 00:39:22 +0200
Message-ID: <5449837C.7080305@fussenegger.info>
Date: Fri, 24 Oct 2014 00:38:52 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <20141023174537.GW19158@mournblade.imrryr.org> <5449463D.7080904@fussenegger.info> <20141023183637.GX19158@mournblade.imrryr.org> <03546F3D-816C-481A-A577-9797855A9DED@pahtak.org> <20141023200134.GY19158@mournblade.imrryr.org>
In-Reply-To: <20141023200134.GY19158@mournblade.imrryr.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010509010801050004050608"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mgXfV8AdJ-q_cIK5nyEpz5jTv_Q
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 22:39:28 -0000

This is a cryptographically signed message in MIME format.

--------------ms010509010801050004050608
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

On 10/23/2014 10:01 PM, Viktor Dukhovni wrote:
> On Thu, Oct 23, 2014 at 03:35:59PM -0400, Stephen Checkoway wrote:
>
>> On Oct 23, 2014, at 2:36 PM, Viktor Dukhovni  =
wrote:
>>
>>> The number of key sets is irrelevant, all that matters is how long
>>> each one is retained.  Postfix defaults to 2 hours (1 hour encrypt
>>> and 1 hour decrypt).  With N keysets, you'd have (T encrypt, (N-1)*T
>>> decrypt).
>> This seems perfectly reasonable (both for general N and for
>> specific N =3D 2 or N =3D 3). But does it make any difference from a
>> protocol perspective? The only way a client could tell if a server
>> is doing something wrong is if the client knows the upper limit on
>> the ticket's validity  NT and sends a ticket after that time which
>> the server accepts.
> OpenSSL at least enforces the N*T time-limit on sessions, and in
> case would not be able to decrypt a session ticket whose key has
> been discarded.  So Postfix sets 2*T as the session lifetime, and
> as a result if a session ticket is decrypted the session will not
> be accepted.

With N =3D 2 your tickets are either T or 2 * T, depending on the time th=
e=20
client received the ticket. The client sends the ticket to the server=20
expecting to continue were it left of but instead ends up with a full=20
new handshake because the ticket is rejected, although the lifetime=20
indicates that it's valid. (Of course no big deal.)

With N =3D 3 your ticket is always 2 * T, no matter when the client=20
received the ticket. I tried to illustrate that in my simple drawing[1]=20
and its the reasoning behind 3 key sets.

That's also were I see the difference for the protocol because all=20
clients are treated equally in terms of ticket lifetime and can trust=20
that they aren't storing garbage tickets (assuming it was configured=20
correctly, but that could be handled by the library).

Richard

[1] http://pastebin.com/1iAatbWm


--------------ms010509010801050004050608
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjMyMjM4NTJaMCMGCSqGSIb3DQEJBDEWBBRT58KkrC4sCvyNJc6Jp5K3JRTLPTBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEAn8pYhoe2zclSHnwRAp0vciGKRkV5
fU/5eDANtipnkAZLvh+D17LaswmiyMF8/+lUNz101ngN12PI3FSoZS6V47gqFUMxP7pRnONd
fJixV3p53W8AprsVqPCAPHo/wN9cbmf+Zk60Au+l9NmUKmP0p0rPPmE/mu+3o4dewKqNewuB
5wxApMMYbJvqQbIgnYiCPu85T/xQHfjv0c1PmEFQichP+Sir/xcfeNNYLCtlQy5AaCEu2alg
FhpUz7qm7Ru72CjU+ojVFWENca4br3qMwa3wSP5V6cuQifdrp3T9PFxsXFtg6McEwG/x54y6
ig2KI1KcFa3ySIo6hFvg3uUFagAAAAAAAA==
--------------ms010509010801050004050608--


From nobody Thu Oct 23 15:52:50 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F1F1A8731 for ; Thu, 23 Oct 2014 15:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZwshnR7UGUh for ; Thu, 23 Oct 2014 15:52:46 -0700 (PDT)
Received: from mx208.easyname.com (mx208.easyname.com [212.232.25.164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3121A7016 for ; Thu, 23 Oct 2014 15:52:46 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XhRFK-0001XI-Jh for tls@ietf.org; Fri, 24 Oct 2014 00:52:44 +0200
Message-ID: <544986A3.6010801@fussenegger.info>
Date: Fri, 24 Oct 2014 00:52:19 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <20141023174537.GW19158@mournblade.imrryr.org> <5449463D.7080904@fussenegger.info> <20141023183637.GX19158@mournblade.imrryr.org> <54494F20.7060002@fussenegger.info> <20141023200702.GZ19158@mournblade.imrryr.org>
In-Reply-To: <20141023200702.GZ19158@mournblade.imrryr.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040700050005050509010106"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yrWuWoMek-uiJRGcf5UAwyFCvPs
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 22:52:49 -0000

This is a cryptographically signed message in MIME format.

--------------ms040700050005050509010106
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 10/23/2014 10:07 PM, Viktor Dukhovni wrote:
> On Thu, Oct 23, 2014 at 08:55:28PM +0200, Richard Fussenegger wrote:
>> I didn't implement it but nginx requires 48 B otherwise it's not worki=
ng and
>> that's definitely more than only key and mac. Maybe the complete thing=
 is
>> broken in nginx then? [1]
>
> The reason nginx has 48 bytes is that it stores a 16 byte name,
> followed by a 16-byte (AES-128) key and a 16-byte HMAC secret.

Oh silly me, I could have found that myself:=20
https://github.com/nginx/nginx/blob/master/src/event/ngx_event_openssl.h#=
L99-L107

> Postfix uses 16 + 32 + 32 =3D 80, because the key is for AES-256 and
> the HMAC key for SHA2-256 is also chosen to be 256 bits.
>
> The nginx implementation can be "strengthened" from AES-128 to
> AES-256 just in case someone wants to burn a few million years of
> a 4GW power plant to brute force a session ticket on a classical
> computer, or future quantum computers can search a 2^128 key space
> in 2^64 time.

But then nginx needs additional code, as you wrote earlier. It would be=20
better (and that's also what the nginx devs want) if the library takes=20
care of all that. Right now nginx has not a single line of code for=20
session tickets (beside that function for external key sets). Well, we=20
can only hope that you might take care of that and commit some OpenSSL=20
code. ;-)

Richard


--------------ms040700050005050509010106
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjMyMjUyMTlaMCMGCSqGSIb3DQEJBDEWBBS8AcmuiroP0HpAZTFxbkGKUB9kUDBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEAN77ri4uqSAFH5aJP/9egv0xIyGQJ
TM6PiKjimKezw21mRUl4sWpfYIWaDc6MizAdiOoKMOr5OD8I1Fppxwces59TLHmPFPc45h//
m6Rzvtlb5dXZLw7fXHU4mwlF3rG2hk2ZM5aI6kV0TnG49NStbqEhetBlFFoiwNl9VVUJMYu+
qkDv38zU2sfTve1atlVUS5VahRM7dn54jXK2bVIX1RfhUjZHLud4MWyQxWwzlsrO6hrJfK35
K9TOfXSZ89a/vTk+RoinD4BLmoa1VIy4OOHZaPtwu7Hi3m2aVOkVgzppsP5DycDqd1p7Jbh9
YJbsXsFLK9QSN4RecIF921YAiAAAAAAAAA==
--------------ms040700050005050509010106--


From nobody Thu Oct 23 15:58:26 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00C71A7031 for ; Thu, 23 Oct 2014 15:58:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd37zj5B591K for ; Thu, 23 Oct 2014 15:58:21 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05DC51A6FE0 for ; Thu, 23 Oct 2014 15:58:21 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 10BDC2AB2EF; Thu, 23 Oct 2014 22:58:20 +0000 (UTC)
Date: Thu, 23 Oct 2014 22:58:20 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141023225819.GA19158@mournblade.imrryr.org>
References:  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <20141023174537.GW19158@mournblade.imrryr.org> <5449463D.7080904@fussenegger.info> <20141023183637.GX19158@mournblade.imrryr.org> <03546F3D-816C-481A-A577-9797855A9DED@pahtak.org> <20141023200134.GY19158@mournblade.imrryr.org> <5449837C.7080305@fussenegger.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5449837C.7080305@fussenegger.info>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5JzBMka-INix87wAsV6eW0VpfAI
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 22:58:23 -0000

On Fri, Oct 24, 2014 at 12:38:52AM +0200, Richard Fussenegger wrote:

> With N = 2 your tickets are either T or 2 * T, depending on the time the
> client received the ticket. The client sends the ticket to the server
> expecting to continue were it left of but instead ends up with a full new
> handshake because the ticket is rejected, although the lifetime indicates
> that it's valid. (Of course no big deal.)

This is not true, I only promise the client a lifetime of T, so
the client asks for a new session after T anyway.  And the time
the ticket is good for is not discrete, it varies uniformly between
T and 2*T.

> With N = 3 your ticket is always 2 * T, no matter when the client received
> the ticket.

Not true, it varies uniformly between 2*T and 3*T.  The client
lifetime hint should be 2*T in this case.

-- 
	Viktor.


From nobody Thu Oct 23 16:01:09 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A783C1A6F61 for ; Thu, 23 Oct 2014 16:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3ZzP16xjDj2 for ; Thu, 23 Oct 2014 16:00:56 -0700 (PDT)
Received: from mx202.easyname.com (mx202.easyname.com [212.232.28.123]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021E81A6F66 for ; Thu, 23 Oct 2014 16:00:56 -0700 (PDT)
Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XhRNE-0007Yx-AA for tls@ietf.org; Fri, 24 Oct 2014 01:00:54 +0200
Message-ID: <5449888C.6030201@fussenegger.info>
Date: Fri, 24 Oct 2014 01:00:28 +0200
From: Richard Fussenegger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References:  <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <20141023174537.GW19158@mournblade.imrryr.org> <5449463D.7080904@fussenegger.info> <20141023183637.GX19158@mournblade.imrryr.org> <03546F3D-816C-481A-A577-9797855A9DED@pahtak.org> <20141023200134.GY19158@mournblade.imrryr.org> <5449837C.7080305@fussenegger.info> <20141023225819.GA19158@mournblade.imrryr.org>
In-Reply-To: <20141023225819.GA19158@mournblade.imrryr.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080703010408070206070701"
X-ACL-Warn: X-DNSBL-v4bl
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IZbviClG6VNGfH2CNVQt5ASPies
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 23:01:00 -0000

This is a cryptographically signed message in MIME format.

--------------ms080703010408070206070701
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

On 10/24/2014 12:58 AM, Viktor Dukhovni wrote:
> On Fri, Oct 24, 2014 at 12:38:52AM +0200, Richard Fussenegger wrote:
>
>> With N =3D 2 your tickets are either T or 2 * T, depending on the time=
 the
>> client received the ticket. The client sends the ticket to the server
>> expecting to continue were it left of but instead ends up with a full =
new
>> handshake because the ticket is rejected, although the lifetime indica=
tes
>> that it's valid. (Of course no big deal.)
> This is not true, I only promise the client a lifetime of T, so
> the client asks for a new session after T anyway.  And the time
> the ticket is good for is not discrete, it varies uniformly between
> T and 2*T.

Ah, of course if you advertise T then everything is alright. I got you=20
wrong there.

>> With N =3D 3 your ticket is always 2 * T, no matter when the client re=
ceived
>> the ticket.
> Not true, it varies uniformly between 2*T and 3*T.  The client
> lifetime hint should be 2*T in this case.
>

Yap, 2 * T for the lifetime in case of N =3D 3.

Richard


--------------ms080703010408070206070701
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6gAwIBAgIDCg8OMA0GCSqGSIb3DQEB
CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNTI2MTUwNDI3
WhcNMTUwNTI3MTMyMzA4WjBMMSEwHwYDVQQDDBhyaWNoYXJkQGZ1c3NlbmVnZ2VyLmluZm8x
JzAlBgkqhkiG9w0BCQEWGHJpY2hhcmRAZnVzc2VuZWdnZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANUTzR7zWF0/aLq1wIZyd91Mf162kjHaP1YYIbkTxCWGVo6E
EIDCb3Xs1mW65ekj/SOUgMsAhvvRkP1Yq1z7e9kGU0WOS1/6iBbdHG4J8nsn5V/eUSvm0y69
8/ydgdBpyY7zqNXDyOX7i4UeNjr/a1kzeOdhMJC7dztGtB7G7xlM2l7bCihImMl1QXrQ3uFo
iJ1Uv+LkhDFN6iTDOeZSJ/uLB3AIfy2Fe9vQ6SWnCZLOjZEpNchQq0PQiSY2WqVsaL9HMIc+
uBBw2gDvTumiX+ep6OvsMMTMWPmiEekOfFb+Hy7qE+3aen2LLAR5c+uEixjTYoc1b3sWsR/i
FuQYm9cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6BtPMqCupqE8zZwqTTY5hjLjkDUwHwYD
VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYcmljaGFyZEBmdXNz
ZW5lZ2dlci5pbmZvMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUF
BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz
IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlk
YXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNl
IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJl
bHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH
MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG
9w0BAQsFAAOCAQEAfs3EhzCgjATGsrfKq5r49CBgwbeVoLsF3oPeuMyntwrcjy32omj0eMo2
oRK9O7IQRDnIvhHxQ/QkpBUWo/NLImqzOdDw2Q4GR+1f674MV4VV/fTP005lFW4IhcRvWz79
D4upsR03kzJtLuWb54UHlKEpFfSAqIgguO2jXilYMFaZHmuO+oH6dKzymHnNf8JJFK33NyFm
LGE6pyVns2VOiroixsDVFiU+u3IiiIYyV3sEAy2OZrd/+kO+m2zYAlv4YA79S605zTb3Ybka
Meujj260u8tv5FZVwNbTdWb+28o5Kb/0fncfzi4x8R3UEc6TctJUPStfoy47qqfj3TgvmDGC
A90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoPDjAJ
BgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEwMjMyMzAwMjhaMCMGCSqGSIb3DQEJBDEWBBR6tBwcjOfKmoPcPACe3c9V9iLC6TBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIDCg8OMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMKDw4wDQYJKoZIhvcNAQEBBQAEggEAnaCzSpKO5fdqlJPLlkUkqsXZC5Hg
ZXEO3JUv46q3zy3vOcluSVFA4+ngAZjWVc515hbqpyw4JfF/niX1D8Y6temILxwTkauLrK1W
ghFRdA0DdptVwicDYLBkwzk5TAbr8tLNx47lr9q3aoDuc9RFaPzpJD9AN2NVsErIqLsv2GjV
TFbXmftETZ9DxOVISbjDRfPVU3KsJAiB9PtU7Y9yOZ1j+MuoYtqIf1kg8GXOmb7OrRw0Tk8Q
4i6qP15wMYYEmDDMoWh1WduR4X3c3rBhmRFxNmwaLuJW9990hpmvgxTc1Ex6p4MQT2F42QG3
62iz5ZyV6xlKcCsEkycFeKxiJQAAAAAAAA==
--------------ms080703010408070206070701--


From nobody Thu Oct 23 18:08:08 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA941AD62B for ; Thu, 23 Oct 2014 18:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cup7ewkeeAaX for ; Thu, 23 Oct 2014 18:07:56 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 34C1D1AD61D for ; Thu, 23 Oct 2014 18:07:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3571DBE2F; Fri, 24 Oct 2014 02:07:53 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1SDKIZ1-SeS; Fri, 24 Oct 2014 02:07:52 +0100 (IST)
Received: from [10.87.48.12] (unknown [86.46.20.206]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0568CBE20; Fri, 24 Oct 2014 02:07:52 +0100 (IST)
Message-ID: <5449A667.9040105@cs.tcd.ie>
Date: Fri, 24 Oct 2014 02:07:51 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Salz, Rich" , "tls@ietf.org" 
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9Fp8k_uizgtjnS6sxP8w3mmLKeo
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 01:08:01 -0000

Hiya,

On 23/10/14 21:49, Salz, Rich wrote:
>> I think there is a significant difference between the security (in
>> particular confidentiality) one gets with good and dodgy algorithms
>> which is sufficient to argue that the OS design pattern is
>> inappropriate to use with such dodgy algs.
> 
> I'm having trouble parsing things.  You don't mean "both good and
> dodgy," but rather "good compared with dodgy" or "good contrasted
> with dodgy"

Yep. I badly write:-) Fair comment though, I wasn't clear so
apologies. As you guessed, what I meant was:

  OS is a fine design pattern. Algorithms can be considered-good
  or dodgy. AES is considered-good. RC4 is dodgy. OS requires
  considered-good algorithms (I think). With dodgy algorithms
  (esp. with ciphertext-only attacks expected soon) OS is no
  better than cleartext for confidentiality. So we ought say
  to not use RC4 when following the OS design pattern.

> Sorry, you IE folks are just too good with words for a poor old yank
> like me :)

And meaninglessly but with more apologies this time to the
estates of Beckett and Joyce:

  Pervasive monitors record, having no alternative, nothing new.
  We may be startled as by a violation of our own privacy.
  As if it wasn't broken already.

Hopefully the latter is sufficiently .ie to pass mustard. And
now you've suggested it, I quite like the idea of Joyce
transcribing PM recordings, and sending those to Beckett the
analyst:-)

Cheers,
S.


> 
> -- Principal Security Engineer, Akamai Technologies IM:
> rsalz@jabber.me Twitter: RichSalz
> 


From nobody Thu Oct 23 22:53:50 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581681ACFC5 for ; Thu, 23 Oct 2014 22:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_oxRgAG7KML for ; Thu, 23 Oct 2014 22:53:47 -0700 (PDT)
Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA7E1A88C5 for ; Thu, 23 Oct 2014 22:53:47 -0700 (PDT)
Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-02v.sys.comcast.net with comcast id 6ttl1p0094s37d401ttn8i; Fri, 24 Oct 2014 05:53:47 +0000
Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-01v.sys.comcast.net with comcast id 6ttl1p0044uhcbK01ttl3z; Fri, 24 Oct 2014 05:53:46 +0000
Message-ID: <5449E969.9000800@brainhub.org>
Date: Thu, 23 Oct 2014 22:53:45 -0700
From: Andrey Jivsov 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: "tls@ietf.org" 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
In-Reply-To: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414130027; bh=bQQvsmxNgklUnsiK2eB+fQ/0eT791bhUlXDY20h7WAE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LKsinUZYYCV/5kKEWlaqD4AJ3jg2ZH0/We98H+tmFFHBCI0xC4lAc08ttlHVBHEBx l4iHuZzahTQ072okC47SI/v6rIGltNKbeLf8MBA4KStufjMmCuGRTW2P9vJMrPCKt7 BV4BGsqPhtvy7/PYbhh/Vx8pKTitju/gO8Mce9giMLGB6WkKFy5YIliA3yl2qAakxD hFkZDaZ1OMbohpSkgQX40sOCSAJZkYDqWQ4rsSdDDAlKbjCeoqtFJCV4/JMIYN19LI IEYCMTXsVyVKXmAzgOK6tHj2ScNpWNlJGbYA39esy96PwfqXxMgboUzg/kb0eausJB mQQgu+uJTtBeA==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Fcm_lUazUB29a4VO1a2280fuEEk
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 05:53:49 -0000

Server list of acceptable ciphersuites is sometimes protocol-specific. 
For example, AES-GCM suites are associated with TLS1.2.

There may be ciphersuites that apply to all protocols but only 
configured to be available with lower ones on some servers. For example, 
DES-CBC3-SHA (or RC4-SHA, etc) might be made available for SSL3.0 only.

Let's assume that the server supports all protocols SSL3.0-TLS1.0, but 
this server supports DES-CBC3-SHA with SSL3.0 only.

Assume that a client only negotiates DES-CBC3-SHA (or that this would be 
the only intersection)

Client does {DES-CBC3-SHA} with TLS1.2 in ClientHello. The pair 
negotiates DES-CBC3-SHA with SSL3.0.

Client decides to drop to TLS1.1 (due to network glitch, etc). It SHOULD 
do {DES-CBC3-SHA,TLS_FALLBACK_SCSV} with TLS1.1 per sec 4. The server 
MUST fail with inappropriate_fallback per sec 3.

Is it a good idea to reject a more secure protocol than the server can 
possibly negotiate with this client? Did I interpret the draft correctly?

( The scenario applies in other cases when you adjust some of values 
here. For example, we expect TLS1.3 intolerant servers, so TLS1.2+SCSV 
was advocated in this case this list. The server is expected to fail 
with inappropriate_fallback even when it doesn't have a match with 
ciphersuites associated with TLS1.2. )

Thank you.


From nobody Thu Oct 23 23:46:36 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EBF1A6F3E for ; Thu, 23 Oct 2014 23:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNewX3LrkBoX for ; Thu, 23 Oct 2014 23:46:34 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 36CBA1A1B74 for ; Thu, 23 Oct 2014 23:46:34 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8903A475E5; Fri, 24 Oct 2014 06:46:33 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 7ABA6475DF; Fri, 24 Oct 2014 06:46:33 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 37F602036; Fri, 24 Oct 2014 06:46:33 +0000 (GMT)
Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 24 Oct 2014 02:46:32 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Fri, 24 Oct 2014 02:46:32 -0400
From: "Salz, Rich" 
To: Stephen Farrell , "tls@ietf.org" 
Date: Fri, 24 Oct 2014 02:46:29 -0400
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: Ac/vJvgu2c9TgOMyTWe/YZw0X1PStAALwbqQ
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF6520E@USMBX1.msg.corp.akamai.com>
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie>
In-Reply-To: <5449A667.9040105@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KzyUCs5IxaF7vtmmDT0WCDTGags
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 06:46:35 -0000

PiAgIE9TIGlzIGEgZmluZSBkZXNpZ24gcGF0dGVybi4gQWxnb3JpdGhtcyBjYW4gYmUgY29uc2lk
ZXJlZC1nb29kDQo+ICAgb3IgZG9kZ3kuIEFFUyBpcyBjb25zaWRlcmVkLWdvb2QuIFJDNCBpcyBk
b2RneS4gT1MgcmVxdWlyZXMNCj4gICBjb25zaWRlcmVkLWdvb2QgYWxnb3JpdGhtcyAoSSB0aGlu
aykuIFdpdGggZG9kZ3kgYWxnb3JpdGhtcw0KPiAgIChlc3AuIHdpdGggY2lwaGVydGV4dC1vbmx5
IGF0dGFja3MgZXhwZWN0ZWQgc29vbikgT1MgaXMgbm8NCj4gICBiZXR0ZXIgdGhhbiBjbGVhcnRl
eHQgZm9yIGNvbmZpZGVudGlhbGl0eS4gU28gd2Ugb3VnaHQgc2F5DQo+ICAgdG8gbm90IHVzZSBS
QzQgd2hlbiBmb2xsb3dpbmcgdGhlIE9TIGRlc2lnbiBwYXR0ZXJuLg0KDQpUaGVyZSdzIGEgdm9j
YWwgbWlub3JpdHkoPykgd2hvIHN0cm9uZ2x5IGRpc2FncmVlcyB3aXRoIHRoaXMsIHBhcnRpY3Vs
YXJseSB0aGUgbGFzdCBzZW50ZW5jZS4NCg0KSSBhc2sgdGhhdCB0aGUgVExTIFdHIGNoYWlycyBk
ZXRlcm1pbmUgY29uc2Vuc3VzIHByZXR0eSBkYXJuIHF1aWNrbHkuDQoNCi0tICANClByaW5jaXBh
bCBTZWN1cml0eSBFbmdpbmVlciwgQWthbWFpIFRlY2hub2xvZ2llcw0KSU06IHJzYWx6QGphYmJl
ci5tZSBUd2l0dGVyOiBSaWNoU2Fseg0KDQoNCg==


From SRS0=P+xR=7P=acm.org=bmoeller@srs.kundenserver.de  Fri Oct 24 02:58:53 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8864C1A8963 for ; Fri, 24 Oct 2014 02:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvMQLOE_2T9W for ; Fri, 24 Oct 2014 02:58:52 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033C21A894D for ; Fri, 24 Oct 2014 02:58:51 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0LwmZo-1YAOw53qHY-016LIg; Fri, 24 Oct 2014 11:58:50 +0200
Received: by mail-qa0-f51.google.com with SMTP id k15so639434qaq.24 for ; Fri, 24 Oct 2014 02:58:47 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.170.220.8 with SMTP id m8mr4920218ykf.48.1414144727716; Fri, 24 Oct 2014 02:58:47 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Fri, 24 Oct 2014 02:58:47 -0700 (PDT)
In-Reply-To: <5449E969.9000800@brainhub.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5449E969.9000800@brainhub.org>
Date: Fri, 24 Oct 2014 11:58:47 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11390932281ccb0506283a0d
X-Provags-ID: V02:K0:BtcrtUfcKDC/2hWOSfATOTGnNiPqsWTGYi/5v0t8JG9 UYvmW9Ep7hM2wWb9K20f7FF+TWUpx5Xiv5k4eUQxrY2Jr80gNt hOKC8OKt7wKy7vOf9J3n+9d03n5iYSaEnxW/1BhC9jcZNGuYf+ rjRCLBcSOwMz969hZgMzZ6COJCfxq6vLCVAMnLpkinGcuNh1Mt d9PJDCTW245/+njJrY+GUHsrIfD51J8ocbx8PnEnHTogGn2DMx jGtJRcR27G5Dw9pttsVXmHjXYEiWDiOeERb7wyvyG0BRC29hew I9gJciOVr1+7en/vi45jO2oOzKJBNJCKvPOmXZYuS7K1zf4CEM xwCChzl9kCMtIp+ofAiyz5E/1ufGKGAm4G8UlbpkTB6WJhzbN0 GohTyKUua9mm60sJAUgkplaYftWRuzDdRvP92oYUwz9htgoCMO 0D8AV
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/b8qcMEGRwlM0w-ghv13WAqnprtc
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 10:01:13 -0000

--001a11390932281ccb0506283a0d
Content-Type: text/plain; charset=UTF-8

Andrey Jivsov :

Client decides to drop to TLS1.1 (due to network glitch, etc). [...] The
> server MUST fail with inappropriate_fallback per sec 3.
>
> Is it a good idea to reject a more secure protocol than the server can
> possibly negotiate with this client?


In this case, the connection really fails due to the network glitch. If the
client wasn't attempting fallback retries, it would similarly fail. (This
could happen independently of the cipher suites that the server accepts.)

In the kind of hypothetical scenario that you describe, it indeed wouldn't
cause a reduction in security to accept the connection instead of failing,
but optimizing for corner cases like this one doesn't seem reasonable: it
necessarily would make the mechanism more complex overall.

(The server behavior that you describe also would be really odd. The CBC
cipher suites are more broken in SSL 3.0 than in TLS 1.0, and more broken
in TLS 1.0 than in TLS 1.1. If the server *does* support one of the newer
protocol versions, why would it only support the most broken incarnation of
that cipher suite?

Also note that in the *specific* hypothetical scenario that you describe,
the server actually would accept the fallback retry: you said that TLS 1.0
is the highest protocol version supported by the server; this is not higher
than ClientHello.client_version in the TLS 1.1 retry, so the server
wouldn't reject.)

Bodo

--001a11390932281ccb0506283a0d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Andr=
ey Jivsov <crypto@brainhub.org>:


Client decides to drop to TLS1.1 (due to network glitch, etc). [...]=C2=A0T=
he server MUST fail with inappropriate_fallback per sec 3.



Is it a good idea to reject a more secure protocol than the server can poss=
ibly negotiate with this client?

In this ca=
se, the connection really fails due to the network glitch. If the client wa=
sn't attempting fallback retries, it would similarly fail. (This could =
happen independently of the cipher suites that the server accepts.)=C2=A0

In the kind of hypothetical scenario that you descr=
ibe, it indeed wouldn't cause a reduction in security to accept the con=
nection instead of failing, but optimizing for corner cases like this one d=
oesn't seem reasonable: it necessarily would make the mechanism more co=
mplex overall.

(The server behavior that you descr=
ibe also would be really odd. The CBC cipher suites are more broken in SSL =
3.0 than in TLS 1.0, and more broken in TLS 1.0 than in TLS 1.1. If the ser=
ver *does* support one of the newer protocol versions, why would it only su=
pport the most broken incarnation of that cipher suite?

Also note that in the *specific* hypothetical scenario that you descr=
ibe, the server actually would accept the fallback retry: you said that TLS=
 1.0 is the highest protocol version supported by the server; this is not h=
igher than ClientHello.client_version in the TLS 1.1 retry, so the server w=
ouldn't reject.)

Bodo


--001a11390932281ccb0506283a0d--


From nobody Fri Oct 24 03:43:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3101A8983 for ; Fri, 24 Oct 2014 03:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2QBWWQD_vRG for ; Fri, 24 Oct 2014 03:43:42 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BAE471A038B for ; Fri, 24 Oct 2014 03:43:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E46C5BE0E; Fri, 24 Oct 2014 11:43:41 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLxRjQAF8ULl; Fri, 24 Oct 2014 11:43:41 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B34B4BE3E; Fri, 24 Oct 2014 11:43:41 +0100 (IST)
Message-ID: <544A2D5E.1000200@cs.tcd.ie>
Date: Fri, 24 Oct 2014 11:43:42 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Salz, Rich" , "tls@ietf.org" 
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF6520E@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF6520E@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ia101xzsibwmVd7L3nljJUdnP5E
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 10:43:44 -0000

On 24/10/14 07:46, Salz, Rich wrote:
>> OS is a fine design pattern. Algorithms can be considered-good or
>> dodgy. AES is considered-good. RC4 is dodgy. OS requires 
>> considered-good algorithms (I think). With dodgy algorithms (esp.
>> with ciphertext-only attacks expected soon) OS is no better than
>> cleartext for confidentiality. So we ought say to not use RC4 when
>> following the OS design pattern.
> 
> There's a vocal minority(?) who strongly disagrees with this,
> particularly the last sentence.

Actually I think only Viktor and I have really gotten into
that part of the discussion. I mean about how OS and RC4
interact. Yes, there are others who'd prefer to go slower
deprecating RC4 or whatever, but their issues aren't related
to OS I think. (And just in case, OS here == Opportunistic
Security [1]).

S.

[1] https://tools.ietf.org/html/draft-dukhovni-opportunistic-security


> 
> -- Principal Security Engineer, Akamai Technologies IM:
> rsalz@jabber.me Twitter: RichSalz
> 
> 


From nobody Fri Oct 24 03:50:48 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22C21A8993 for ; Fri, 24 Oct 2014 03:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUouHMfuWnof for ; Fri, 24 Oct 2014 03:50:46 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124AF1A1B14 for ; Fri, 24 Oct 2014 03:50:46 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9OAoaIl014639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 24 Oct 2014 06:50:36 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9OAoXU1025268 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2014 06:50:35 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Fri, 24 Oct 2014 12:50:33 +0200
Message-ID: <1730049.IgUL0REWQP@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <54493904.7010807@fussenegger.info>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LqOBY87pKZyGBP4LfCDVU8rixRc
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 10:50:47 -0000

On Thursday 23 October 2014 19:21:08 Richard Fussenegger wrote:
> On 10/23/2014 4:03 PM, Hubert Kario wrote:
> > While it may negotiate AES-256 (because it wants to interoperate with
> > clients that are configured to not to present weaker ciphers), doesn't
> > mean that it as a whole is configured to the 256 bit level of
> > security. With TLS1.2 it may sign the (EC)DHE parameters using SHA-1,
> > it may use RSA key exchange using only 2048 bit keys, it may be just a
> > local proxy server that is hard coded to connect using AES-128 with
> > the backed servers over open Internet. Yes, server should encrypt the
> > tickets with as strong algorithm as its most secure cipher, but there
> > are many situations where it's not necessary. "MUST" is certainly not
> > applicable.
> 
> Those are good and valid arguments for a RECOMMENDED regarding session
> ticket/token key algorithms or simply dropping one word and uppercasing
> another does the trick (?):

yes, I agree.

> 
> https://tools.ietf.org/html/rfc5077#section-5.5
> 
> >    o  The keys and cryptographic protection algorithms should be at
> >    
> >       least 128 bits in strength.  Some ciphersuites and applications
> > 
> > -     may require cryptographic protection greater than 128 bits in
> > +     REQUIRE cryptographic protection greater than 128 bits in
> > 
> >       strength.
> 
> But the MUST regarding key rotation, key discarding, and key count hard
> limits is still appropriate in my opinion because PFS is a MUST in TLS
> 1.3 (unless this has changed and I didn't read about it).

Yes, while a large key size is recommended ("SHOULD"), a frequent key rotation 
(in order of days) is a "MUST" with shorter time scales recommended, given 
other parts of TLS 1.3.

-- 
Regards,
Hubert Kario


From nobody Fri Oct 24 04:32:49 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F93B1A8A96 for ; Fri, 24 Oct 2014 04:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNes1SVTm9-4 for ; Fri, 24 Oct 2014 04:32:41 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3061B1A8993 for ; Fri, 24 Oct 2014 04:32:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414150361; x=1445686361; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=2Zf5JVprgrFLpQDpdyglSPjqNgBYFTaUgggNFPLf10g=; b=LTrnEDo79ETzDu0WVEhGjqdKdyeqxE9VQSD7WatqL0iKB+10BjEBkPpR bvasJ7Pfog1j/wUjtt0ko1GG6SLyaj1Qas9Hb7wRny7AglNpOJfCJGrf8 pWSAB0SA6iav7Ij16YiAlitgrGgCd0L5pM14ibD21QLGdEsmqnAkD6mQH Y=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="285555534"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 Oct 2014 00:32:37 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Sat, 25 Oct 2014 00:32:36 +1300
From: Peter Gutmann 
To: "dkg@fifthhorseman.net" , "tls@ietf.org" 
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
Thread-Index: Ac/vfjU+F32OZ2ncSo2nWThJw8zdLQ==
Date: Fri, 24 Oct 2014 11:32:35 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D7684@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Fw40vAt3tf763N_d8-umboCan7U
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 11:32:46 -0000

Daniel Kahn Gillmor  writes:=0A=
=0A=
>yes, and that's a deliberate choice, as documented (perhaps not well enoug=
h?)=0A=
>in the draft under "Choice of Groups".=0A=
=0A=
The reasons given aren't very convincing, it's just "they're too widely use=
d".=0A=
On the one hand that could be a problem, but it's also a huge advantage,=0A=
you're just documenting existing practice rather than forcing everyone to=
=0A=
switch to an entirely new set of groups they've never seen before.  If I'm=
=0A=
using OpenSSL (which it seems two thirds of the planet is) I just call=0A=
get_rfc2409_prime_1024() or get_rfc3526_prime_2048() or whatever, for prett=
y=0A=
much any version of OpenSSL in current use, and it works.  Apache already u=
ses=0A=
these parameters by default (or did, I haven't checked recently).  If you w=
ant=0A=
to invent new, nonstandard parameters then by all means feel free to do so,=
=0A=
but don't lock out the existing ones that have been in widespread use for=
=0A=
years.=0A=
=0A=
>Some of the MODP groups (768, 1024, 1536 at least) are also smaller than w=
e=0A=
>should be explicitly supporting in updated tools, so i don't think re-=0A=
>blessing them into another standard is a good idea.=0A=
=0A=
Shorter groups are still required for embedded devices. You're not "blessin=
g"=0A=
them, you're just giving people the option to use them.  If you require the=
=0A=
use of large groups as the current draft does then you're automatically=0A=
excluding it from being used by many embedded devices.=0A=
=0A=
>One counterargument i'm aware of is that systems that want to support both=
=0A=
>sets of groups would need to have a larger table of known moduli. So perha=
ps=0A=
>the argument is that extremely memory-constrained devices running both TLS=
=0A=
>and IPSec (or TLS with SRP) could share a table of known moduli to reduce =
RAM=0A=
>consumption?  =0A=
=0A=
Constrained devices won't be using 2K+ bit groups anyway so in a sense this=
=0A=
isn't a problem, but "solving" things by excluded whole classes of users=0A=
doesn't seem like a good approach to things.=0A=
=0A=
>We had a discussion about the use of e-derived safe primes instead of pi-=
=0A=
>derived safe primes in Toronto, and no one seemed to think that the groups=
=0A=
>currently proposed were any worse than the MODP groups.=0A=
=0A=
They're not worse, but they're also both completely different from the de=
=0A=
facto standard groups and can't be used by whole classes of users.  As I=0A=
mentioned earlier, if you want to introduce fancy new groups then by all me=
ans=0A=
go ahead, but don't lock out existing uses and users.=0A=
=0A=
Peter.=


From nobody Fri Oct 24 06:04:56 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707331A004D for ; Fri, 24 Oct 2014 06:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHBEiMSrjk08 for ; Fri, 24 Oct 2014 06:04:52 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE6D1A004C for ; Fri, 24 Oct 2014 06:04:52 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9D7684@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D7684@uxcn10-5.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Alyssa Rowan 
Date: Fri, 24 Oct 2014 14:04:43 +0100
To: tls@ietf.org
Message-ID: 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/E3XzNKWp6MhKRtWrxqcf2C7X9YQ
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 13:04:54 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 24 October 2014 12:32:35 BST, Peter Gutmann  wrote:

>>Some of the MODP groups (768, 1024, 1536 at least) are also smaller than we should be explicitly supporting in updated tools, so i don't think re-blessing them into another standard is a good idea.
>Shorter groups are still required for embedded devices.

With respect, no, they aren't. 256-bit ECDHE is --> that way. Don't use 1024-bit DHE; use 256-bit ECDHE. More security, more speed, less size; and that's even before CFRG's Christmas present of (X25519|numsp256t1).

Constrained devices are absolutely no excuse for second-or-third-rate crypto. Certainly not today when we know better.

>…you're just giving people the option to use them.

No, it's blessing them even to list them. People will probably implement what we specify. They'll assume we did a good job. If we give people the option to use them, they'll use them. It's inappropriate to use them, because they're widely considered too small to use anymore. So don't list them. Simple.

Technology marches on, I'm afraid; key sizes need to march on too. 768 and 1024 are crackable today by any reasonably well-funded adversary with access to a chip fab, as you well know; 1536 may not be, but I wouldn't chance it anymore as Moore's law benefits the attacker more than embedded devices, attacks always get better over time, and the most pernicious adversaries record traffic in case they can crack it later. It may not be cheap or very practical for them to do so, but we can nevertheless avoid it, so we should.

Keep the groups to >= 2048-bit, please.

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJUSk5qGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6pZcQAKUWhsd8eY7kJjc9bEdFN/bY1xL4qeeE3gj199P89zLfgPGrfVMN
xhya/luKqPg4mrUbXqiVMoAjFxC+RUvN4SHVEcQRX8BUI1t4Z/Dpcm4T9z2nXJYV
3qB3++fJIbD7P9Ep7Q4TQUVMfho5UI1fyVtvG/Hnl4NjrIAW5q5JVkf2urKvfL35
K3oe1UVVoWG83EXMy16YgCAaduwrMQLs+lAFRLvnywTf1e3fj1gfMtq5v0GkzGoJ
5u+ukpesC+B7POlUb6FSKdGEU9NDdojP6g1Uykg2SW4s+Ad8WZ6qTL7verh/AOoJ
9IzF46UOccJtVvWuVGHyYhBtIxUmCJytaAmD7s3hjY0qlTOEqm0WlW0vblXAxXJe
mgCE2k4Ms9fyYf4+t7QBiZ46ZoVkOPQEwhT9V9MgrKdSOdDtgELOJjFh3DK11X0m
IqJ1F8aY5ijxQxFGvJEEt4bWK9HOO9dinNOXC5ObyJouRMp6XviLqwSQcFRXGWsD
x0HiPVmCFe31k8kljeSP2lMVRaEVd49O4PRZYjg2PbdGcZDQ/Rpx5TSB0DN1Ds5E
GdQ8/W5wI/vI/QASTA/DIAZP5FAyYorhOOqvOiamEEhiL5+kQmPAzunS7uSrHPqo
IT5HWPVE3DKbOIBK4aWX5eyymia18Ub+DUOJlE9R9hmsQMEfh7fSjNaD
=pcZG
-----END PGP SIGNATURE-----


From nobody Fri Oct 24 06:37:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0885F1A00B0 for ; Fri, 24 Oct 2014 06:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StsglDJ7f6oj for ; Fri, 24 Oct 2014 06:37:31 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E501A007B for ; Fri, 24 Oct 2014 06:37:31 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 387AC2AB109; Fri, 24 Oct 2014 13:37:29 +0000 (UTC)
Date: Fri, 24 Oct 2014 13:37:29 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141024133728.GI19158@mournblade.imrryr.org>
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5449A667.9040105@cs.tcd.ie>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/m3sWMUjQkKGGQDIF3u1tF_st73M
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 13:37:33 -0000

On Fri, Oct 24, 2014 at 02:07:51AM +0100, Stephen Farrell wrote:

> Yep. I badly write:-) Fair comment though, I wasn't clear so
> apologies. As you guessed, what I meant was:
> 
>   OS is a fine design pattern. Algorithms can be considered-good
>   or dodgy. AES is considered-good. RC4 is dodgy. OS requires
>   considered-good algorithms (I think).

When OS is a just-in-case "upgrade" from cleartext to unauthenticated
encrypted communication, there is requirement for "considered good"
algorithms.  The prime-directive is to not disrupt communication,
only then do we try to encrypt if possible.

Thus, for example, if we're doing STARTTLS with SMTP, the handshake
is:

	C: EHLO amnesiac.example
	S: 250-smtp.example
	S: 250 STARTTLS
	C: STARTTLS
	S: 220 make my day
	C: 
	S: 
	...

The client and server commit to TLS without any prior knowledge of
what cipher suites they might share in common.  If the client's
list is too strict, the server will abort with a TLS alert.  Since
we were willing to send in cleartext had the server not indicated
STARTTLS, any cipher suite (even dodgy) is better than a handshake
failure.

Even if years later some TLA recovers the plaintext after a
crypt-analytic breakthrough finally renders the dodgy vulnerable
at reasonable cost.

The alternative is either cleartext transmission or failure.  The
former is immediately available to the TLA.  The latter is not what
the opportunistic client "signed up for".  It was just trying to
deliver the mail with as much security as is available, but no
more.

Therefore, opportunistic TLS needs to be more permissive.  With
opportunistic TLS stricter policies are counterproductive.

Leaving a cipher suite out is only practical once it is no longer
the best shared cipher with any peers.  Thus we can if we wish
disable EXPORT cipher suites since they are now never used, but it
serves no purpose to do so (they are never used) beyond perhaps
preventing accidents in which a grossly misconfigured peer selects
EXPORT despite having better options.  I have never observed such
an accident.

-- 
	Viktor.


From nobody Fri Oct 24 07:01:42 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA1B1A0158 for ; Fri, 24 Oct 2014 07:01:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtqoGONRMnj2 for ; Fri, 24 Oct 2014 07:01:38 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 558021A014A for ; Fri, 24 Oct 2014 07:01:38 -0700 (PDT)
Received: from [10.70.10.51] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 3D09DF984 for ; Fri, 24 Oct 2014 10:01:35 -0400 (EDT)
Message-ID: <544A5BB3.4000506@fifthhorseman.net>
Date: Fri, 24 Oct 2014 10:01:23 -0400
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0
MIME-Version: 1.0
To: tls@ietf.org
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <20141024133728.GI19158@mournblade.imrryr.org>
In-Reply-To: <20141024133728.GI19158@mournblade.imrryr.org>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="p2Xc0FPPHGjRLSNm0WovbuA8c9v9L4ol5"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fKlQGGyxIa_7pnD_zTK948gNs7Q
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 14:01:41 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--p2Xc0FPPHGjRLSNm0WovbuA8c9v9L4ol5
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 10/24/2014 09:37 AM, Viktor Dukhovni wrote:

> Leaving a cipher suite out is only practical once it is no longer
> the best shared cipher with any peers.  Thus we can if we wish
> disable EXPORT cipher suites since they are now never used, but it
> serves no purpose to do so (they are never used) beyond perhaps
> preventing accidents in which a grossly misconfigured peer selects
> EXPORT despite having better options.  I have never observed such
> an accident.

arguably, there are many such "grossly-misconfigured peers" right now
with respect to RC4 (usually because of misguided attempts to protect
against BEAST, aiui).  These are servers that support something other
than RC4, but select RC4 if a client offers it (even if it was the
client's lowest priority).

So the safest OS approach in the context of a strongly-deprecated cipher
$WEAK_CIPHER, for a client that is willing to ultimately fall back to
cleartext would be, for any given peer P:

 * connect to P and offer TLS without $WEAK_CIPHER
 * if that fails with "no cipher overlap", then:
    * reconnect to P and offer TLS with $WEAK_CIPHER
    * if that fails for any reason, then:
        * reconnect to P with cleartext.

This could probably be further improved by remembering which level of
fallback succeeded on previous attempts, and refusing to fallback further=
=2E

I don't think that any of this needs to go in the current draft, though.
 We should be explicitly and unambiguously rejecting RC4, and people
doing TLS-that-is-willing-to-fall-back-to-cleartext can just muddle
along violating the RFC, since they're not even claiming to make the TLS
communications property guarantees to their users anyway.

	--dkg


--p2Xc0FPPHGjRLSNm0WovbuA8c9v9L4ol5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJUSluzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcHAMQAMencmITTyLSz0oWS4DrYu6E
XnFJkCMgaCn0aK3G2skv/FNoznx2wN/Aoc4NmZufJwDKgOHDGwOJgp3ljeKMeVdR
7IHkQaOtbvsUZMoX46kK/IO78pepFVNG2s9FIbYTDii8fS7Zd+7r3p1BNSXu7q/R
DXObT0PDnptXU55l1Hq5QB6MmA/RioeCxlrOUtRUugvDYzqhQcBOwaAVLW3A9sGc
9ee16kXNhXrTzzCmq98B3X3b8L4rnV+nwbiMGuag5DOrLFPcN0+jVrg++9pLYKYz
CLZkVQPPWjKp3SM6K7X9UTRbSZ23UNm0VpjlROIFwSv3iO7WbE0fNVXbINNxPKtF
ZfGWqOUHHmMOQrILQ/zS+u4L0cynFL5jCSypWzJBXH/3amE0L5ULXDOGt1X7pkCh
RX92rOUEWyhcB9Q42qDPfk05EaJMpvVJoyWvN6wc6RcH4TKcItiI9hxZfHs4TAKI
x9LQI3VBUfzwFDnzDrzbvbmy/JqJNB6WcJgPnrHND9hDQm2yNJJNXb3+hAOJgwy5
a3Uj1ACmJKAW9AINP3qdb+TxUiPqjGBMzNTCFWw1xZ+YEfXOMyYzxAD2QfSxtxVZ
dKz6+ELtAp7euhM7pJc616YOIHMPRnTHFhGbU0a7zt9K+YBF/H5zAyh4H/RjFxjS
VVEfLAT/vHiDOiroxeSV
=Uv1z
-----END PGP SIGNATURE-----

--p2Xc0FPPHGjRLSNm0WovbuA8c9v9L4ol5--


From nobody Fri Oct 24 07:13:26 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF4D1A03A3 for ; Fri, 24 Oct 2014 07:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkrg30kjbeEz for ; Fri, 24 Oct 2014 07:12:51 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66F11A034F for ; Fri, 24 Oct 2014 07:12:19 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D6DB72AB109; Fri, 24 Oct 2014 14:12:15 +0000 (UTC)
Date: Fri, 24 Oct 2014 14:12:15 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141024141215.GL19158@mournblade.imrryr.org>
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <20141024133728.GI19158@mournblade.imrryr.org> <544A5BB3.4000506@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <544A5BB3.4000506@fifthhorseman.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/s7HAWleK5i8nh_mnrUoNcpnJB5A
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 14:13:01 -0000

On Fri, Oct 24, 2014 at 10:01:23AM -0400, Daniel Kahn Gillmor wrote:

> arguably, there are many such "grossly-misconfigured peers" right now
> with respect to RC4 (usually because of misguided attempts to protect
> against BEAST, aiui).  These are servers that support something other
> than RC4, but select RC4 if a client offers it (even if it was the
> client's lowest priority).

[ Note I was responding to Stephen's side note about opportunistic
  security, we're no longer discussing the language of the draft. ]

Indeed if RC4 were always selected for spurious reasons, then one
might be wise to disable it.  We're not there yet, so in practice
opportunistic applications will not immediately change to adhere
to the draft.

> So the safest OS approach in the context of a strongly-deprecated cipher
> $WEAK_CIPHER, for a client that is willing to ultimately fall back to
> cleartext would be, for any given peer P:
> 
>  * connect to P and offer TLS without $WEAK_CIPHER
>  * if that fails with "no cipher overlap", then:
>     * reconnect to P and offer TLS with $WEAK_CIPHER
>     * if that fails for any reason, then:
>         * reconnect to P with cleartext.

That's too much code.  MTAs are not browsers, there are no complex
multi-pass attempts to establish TLS.  TLS either happens or does
not.  If the handshake fails, some will retry in cleartext, others
will skip to the next MX host or defer the mail.

With MTAs the remote end often has connection rate limits, and may
lower the "reputation" of clients that frequently disconnect without
completing a delivery.

> This could probably be further improved by remembering which level of
> fallback succeeded on previous attempts, and refusing to fallback further.

Sorry, MTAs don't maintain SQLite databases with peer history.
There is no interactive user to override stale pinned information.

Browser analogies and strategies work poorly or not at all when
misapplied to SMTP.

-- 
	Viktor.


From nobody Fri Oct 24 07:31:33 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6DB1A00A7 for ; Fri, 24 Oct 2014 07:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STbkwfYEe06Q for ; Fri, 24 Oct 2014 07:31:30 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 87C1A1A0006 for ; Fri, 24 Oct 2014 07:31:28 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A5DCB4862B for ; Fri, 24 Oct 2014 14:31:27 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 9A3D44862A for ; Fri, 24 Oct 2014 14:31:27 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 81C4E1E05B for ; Fri, 24 Oct 2014 14:31:27 +0000 (GMT)
Received: from usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 24 Oct 2014 10:31:26 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Fri, 24 Oct 2014 10:31:26 -0400
From: "Salz, Rich" 
To: "tls@ietf.org" 
Date: Fri, 24 Oct 2014 10:31:23 -0400
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: Ac/vj67BPQJu6M8wTbC7Ay2vOOSRgwAB1Hig
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF65341@USMBX1.msg.corp.akamai.com>
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <20141024133728.GI19158@mournblade.imrryr.org>
In-Reply-To: <20141024133728.GI19158@mournblade.imrryr.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IMvb_htA_V-vm55PH_tsiPXCDjs
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 14:31:31 -0000

> Leaving a cipher suite out is only practical once it is no longer the bes=
t shared
> cipher with any peers. =20

I don't agree with this blanket statement.  Sometimes nothing trumps "somet=
hing is better than nothing."

When the IETF's leading cryptographers say not to use something, then you'r=
e better off with plaintext than a false sense of security for your users.

	/r$

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz


From nobody Fri Oct 24 07:54:27 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FA41A0B00 for ; Fri, 24 Oct 2014 07:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_zgep1yDjee for ; Fri, 24 Oct 2014 07:54:22 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 706A51A0AF1 for ; Fri, 24 Oct 2014 07:54:22 -0700 (PDT)
Received: from [10.70.10.51] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 4019CF984 for ; Fri, 24 Oct 2014 10:54:18 -0400 (EDT)
Message-ID: <544A680F.4080307@fifthhorseman.net>
Date: Fri, 24 Oct 2014 10:54:07 -0400
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0
MIME-Version: 1.0
To: tls@ietf.org
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <20141024133728.GI19158@mournblade.imrryr.org> <544A5BB3.4000506@fifthhorseman.net> <20141024141215.GL19158@mournblade.imrryr.org>
In-Reply-To: <20141024141215.GL19158@mournblade.imrryr.org>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EmiPA6lMJWhTOAiIIJkw0FhCKli0Eqftg"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mDhaqEllY1ggaIy3MS1WARwNTqU
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 14:54:25 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EmiPA6lMJWhTOAiIIJkw0FhCKli0Eqftg
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Victor--

On 10/24/2014 10:12 AM, Viktor Dukhovni wrote:
> On Fri, Oct 24, 2014 at 10:01:23AM -0400, Daniel Kahn Gillmor wrote:
>=20
>> arguably, there are many such "grossly-misconfigured peers" right now
>> with respect to RC4 (usually because of misguided attempts to protect
>> against BEAST, aiui).  These are servers that support something other
>> than RC4, but select RC4 if a client offers it (even if it was the
>> client's lowest priority).
>=20
> [ Note I was responding to Stephen's side note about opportunistic
>   security, we're no longer discussing the language of the draft. ]

yes, agreed.  thanks for making this explicit.

> Indeed if RC4 were always selected for spurious reasons, then one
> might be wise to disable it.  We're not there yet,  so in practice
> opportunistic applications will not immediately change to adhere
> to the draft.

Yep, i understand.  We're not at "always" yet, though some systems (MTAs
as well as HTTP servers, iiuc) are indeed selecting RC4 for spurious
reasons.

>> So the safest OS approach in the context of a strongly-deprecated ciph=
er
>> $WEAK_CIPHER, for a client that is willing to ultimately fall back to
>> cleartext would be, for any given peer P:
>>
>>  * connect to P and offer TLS without $WEAK_CIPHER
>>  * if that fails with "no cipher overlap", then:
>>     * reconnect to P and offer TLS with $WEAK_CIPHER
>>     * if that fails for any reason, then:
>>         * reconnect to P with cleartext.
>=20
> That's too much code.  MTAs are not browsers, there are no complex
> multi-pass attempts to establish TLS.  TLS either happens or does
> not.  If the handshake fails, some will retry in cleartext, others
> will skip to the next MX host or defer the mail.
>=20
> With MTAs the remote end often has connection rate limits, and may
> lower the "reputation" of clients that frequently disconnect without
> completing a delivery.
>=20
>> This could probably be further improved by remembering which level of
>> fallback succeeded on previous attempts, and refusing to fallback furt=
her.
>=20
> Sorry, MTAs don't maintain SQLite databases with peer history.
> There is no interactive user to override stale pinned information.

In the paragraphs above, you seem to be claiming both of:

 (a) MTAs keep state about their peers, so we can't do retries, and
 (b) MTAs don't keep state about their peers, so they can't remember
what they've tried

My understanding as an MTA operator, is that MTAs *do* keep state about
their peers, and have (sometimes complex) logic about delivery choices,
including on a per-destination or per-peer basis.  Whether that state is
an an SQLite database or not, i don't really care.

I agree that it's all "too much code", and i'd love to have a nice
simple clean TLS-only (and good-ciphers-only) MTA that has no fallback
logic.  But that's not going to cut it if we want to interop in today's
world, and if we prioritize delivery over confidentiality and integrity
(which i understand is the traditional prioritization for MTA operators,
and i do it myself).

I also understand that suggesting this behavior without a patch can be
frustrating to MTA developers -- i'm sorry that i don't have time to
produce such a patch for Postfix now.

But that doesn't mean that the proposed logic isn't ultimately a
sensible approach to try to advance confidentiality and integrity goals
without harming deliverability.

If we take the fallback approaches described above, and each fallback
incurs a small delay, to avoid the peer reputation rejection scenarios,
then mail being delivered to RC4-only peers would be minorly delayed
upon first delivery, and mail being delivered to cleartext-only peers
would be doubly delayed for first delivery.

You could also build in a decay of recorded peer state, so that messages
would continue to retry with the best-known level of security for a
given peer, but would eventually fall-back to weaker fallbacks before
discarding the messages as non-deliverable.  In the event of a mail
server that somehow loses better-than-RC4 ciphers or regresses to
non-STARTTLS entirely, messages to that mailserver would be delayed but
not lost.

(this has the nice property "if you want your users to get their mail
faster, you should ensure that your MTA offers stronger security",
thereby tying together usability and security)

Perhaps this discussion might be better continued on UTA, sorry if it's
OT here.

> Browser analogies and strategies work poorly or not at all when
> misapplied to SMTP.

I wrote the entire original message thinking specifically about SMTP, fwi=
w.

Thanks for your work on opportunistic security, both here in the IETF
and on Postfix itself, Victor.  It's exciting to see someone leading the
way forward with this.

Regards,

	--dkg



--EmiPA6lMJWhTOAiIIJkw0FhCKli0Eqftg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJUSmgPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcJRUQAIy6xwJOJZlrWQl9mjC3hsId
QqLa5YRNOwuzhnc9ge7wIJX8v4BOkCb46qS1T8/xUQN8A1vu9cplDiu8417TDDEt
Ok6FxvS7rdsxNBFKOtjb34P93TQS7nk3edBYCJyQhD5CPwDAWcvSA56xMRigQ5NS
EKjufUdEeXYDvgV+xhA2ehHmdCUrnvCqjdZ/XUEtJqU1RSmC/FW8WEOBGXcMW0mg
dqEA9vekMqMa0S36rGt8fGhDaCr94kz3AwpaTkrLfYAvIxv/WYR1t9if6IKB7chC
/Skg3RIu/AtOsREkNBEth/GM6s6eLDwaZv0Sq/YuxAJAt4pXrHf9loGXFPCrnOSs
DiNiHnpENrIP8S3JTkk7cZ6VrEjyoNCqUNmclUFcnLpSmfI4CU2wPtFfCDkVeJ8W
CP3kpmNDam/i/3kHSExxhEb9eWpyPEzO1/u8pL/R8yPmeWhQJ+Bi3qMntNfZ6G27
Y8d0rCu3MiTHzGr76l4gYEVh/9RhxexoeivuRfbE9ZZjaWdCWabcJ1yTh3cH09CM
dv8NZnG5bPgIOrmvfy6kNvxszP5VIpr2VNJhhenmpEJauIrnZ7mchsMG+kLaRTj1
y5ItjuSRw4mxZ/zIO0S66tqEpbf4Vs/td2nOzEdGPPX4z4pLz077lE6/tag0EXun
hajkJ5xgw0FP659rskO+
=FNse
-----END PGP SIGNATURE-----

--EmiPA6lMJWhTOAiIIJkw0FhCKli0Eqftg--


From nobody Fri Oct 24 07:54:47 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC731A19F2 for ; Fri, 24 Oct 2014 07:54:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yW__rFSFXe4 for ; Fri, 24 Oct 2014 07:54:41 -0700 (PDT)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id E1E111A19F1 for ; Fri, 24 Oct 2014 07:54:40 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id s9OEsWS5011696 for ; Fri, 24 Oct 2014 10:54:38 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: "'tls@ietf.org'" 
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: AQHP7h2m71FI0rj2akmyZ4hzz+ycXpw8qMOAgABXIICAAWy3gIAASBaAgADRcoCAAA8PgP//wlLsgAABGCs=
Date: Fri, 24 Oct 2014 14:54:32 +0000
Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC13F5E372@LLE2K10-MBX01.mitll.ad.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [155.34.14.22]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28,  0.0.0000 definitions=2014-10-24_04:2014-10-24,2014-10-24,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410240125
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sK0zQvyFQU2h73HFoFZ-9yNQNjw
Subject: [TLS] Fw:  I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 14:54:44 -0000

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185      =20

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  

----- Original Message -----
From: Blumenthal, Uri - 0558 - MITLL
Sent: Friday, October 24, 2014 10:50 AM=0A=
To: 'rsalz@akamai.com' 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

I disagree. In case of SMTP STARTTLS something *is* better than nothing. It=
 is not about false sense of security - it is about making the adversary's =
job harder when possible as much as possible; realizing that sometimes what=
's possible is not going to be AES256-hard.

P.S. In that case/scenario even ROT13 is better than nothing.

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185      =20

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  

----- Original Message -----
From: Salz, Rich [mailto:rsalz@akamai.com]
Sent: Friday, October 24, 2014 10:31 AM=0A=
To: tls@ietf.org 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

> Leaving a cipher suite out is only practical once it is no longer the bes=
t shared
> cipher with any peers. =20

I don't agree with this blanket statement.  Sometimes nothing trumps "somet=
hing is better than nothing."

When the IETF's leading cryptographers say not to use something, then you'r=
e better off with plaintext than a false sense of security for your users.

	/r$

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From nobody Fri Oct 24 07:55:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621691A19FB for ; Fri, 24 Oct 2014 07:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V725zfIb2cn1 for ; Fri, 24 Oct 2014 07:55:14 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0931A19F5 for ; Fri, 24 Oct 2014 07:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414162514; x=1445698514; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=x3uVshf8hqhFGnS7R/7XnDECsn9lP35/DXARIdTpKk4=; b=AING0CzuhelpDwvCsxWgLcRmabXHC0mWLRUzXpnc3nLbGNQ+BKEBNYRa QcHq5Zadex64iC2kmWEICe9LFnv2Qefvi/inKT51F7SFn6qWAF+F5WtUz T04dhch7KV7DJtXxbALidFlKl+tubZobhSgtEGmYY85r+jbEc2rgvEEDS o=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="285575133"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 Oct 2014 03:55:12 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Sat, 25 Oct 2014 03:55:11 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
Thread-Index: Ac/vmoJJUv7rjslASuKMt2weVdQL5w==
Date: Fri, 24 Oct 2014 14:55:10 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D77B4@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RYhFSzkg_5s7aS4G8r3Y9UPT7u4
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 14:55:21 -0000

Alyssa Rowan  writes:=0A=
=0A=
>>Shorter groups are still required for embedded devices.=0A=
>=0A=
>With respect, no, they aren't. 256-bit ECDHE is --> that way. Don't use 10=
24-=0A=
>bit DHE; use 256-bit ECDHE. More security, more speed, less size;=0A=
=0A=
... and the need to implement an entirely new type of crypto on a constrain=
ed=0A=
device with a ten-year product cycle for which the crypto development budge=
t,=0A=
now that it's already been deployed for several years, is $2.50.  Revving t=
he=0A=
firmware on new products to support a new TLS extension for EDH indication=
=0A=
will probably happen at some point.  Re-doing the crypto to implement and=
=0A=
support ECC may happen in five to ten years, if there's enough code space i=
n=0A=
the flash.=0A=
=0A=
>No, it's blessing them even to list them. People will probably implement w=
hat=0A=
>we specify.=0A=
=0A=
So put in a note saying that use isn't recommended.  This isn't a bunch of=
=0A=
Windows PCs with automatic update turned on, its unknown millions of embedd=
ed=0A=
devices whose firmware is updated when the device falls apart and gets=0A=
replaced, and for which you may get away with a small tweak from time to ti=
me=0A=
but can't do any significant re-engineering once it's type-approved ("it=0A=
works, don't touch it any more").=0A=
=0A=
>Technology marches on, I'm afraid; key sizes need to march on too. 768 and=
=0A=
>1024 are crackable today by any reasonably well-funded adversary with acce=
ss=0A=
>to a chip fab, as you well know; =0A=
=0A=
... who probably won't be using that capability to attack a power meter, or=
 a=0A=
flow monitor.  This isn't protecting nuclear weapons launch facilities, it'=
s=0A=
for remote monitoring of fluid flows, or power metering, or a million other=
=0A=
SCADA applications that merely need better-than-nothing security.  Being ab=
le=0A=
to say "only use this DH group" is an improvement on current practice in wh=
ich=0A=
anything is accepted.=0A=
=0A=
>Keep the groups to >=3D 2048-bit, please.=0A=
=0A=
So you're producing an RFC which will automatically be ignored, in fact whi=
ch=0A=
will *have* to be ignored, by a significant market segment, and they'll sta=
y=0A=
with their existing unverified DH.  The RFC will then have completely faile=
d=0A=
to achieve what it's intended to achieve.=0A=
=0A=
Peter.=0A=


From nobody Fri Oct 24 07:59:58 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80C81A1A02 for ; Fri, 24 Oct 2014 07:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2J8WW3AsPbN for ; Fri, 24 Oct 2014 07:59:54 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F5B1A0AF7 for ; Fri, 24 Oct 2014 07:59:51 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 77CCD2AB2E7; Fri, 24 Oct 2014 14:59:50 +0000 (UTC)
Date: Fri, 24 Oct 2014 14:59:50 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141024145950.GN19158@mournblade.imrryr.org>
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <20141024133728.GI19158@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF65341@USMBX1.msg.corp.akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF65341@USMBX1.msg.corp.akamai.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6dsIlcs9gDSij8q5rkA3GnzbMwk
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 14:59:57 -0000

On Fri, Oct 24, 2014 at 10:31:23AM -0400, Salz, Rich wrote:

> > Leaving a cipher suite out is only practical once it is no longer the best shared
> > cipher with any peers.  
> 
> I don't agree with this blanket statement.  Sometimes nothing trumps "something is better than nothing."
> 
> When the IETF's leading cryptographers say not to use something,
> then you're better off with plaintext than a false sense of security
> for your users.

There is no false sense of security with non-interactive with
unauthenticated opportunistic TLS.  You expect no security, and
none is claimed.  If passive attacks happened to be avoided, that's
gravy, if not, at least cleartext would not have been stronger.

The MTA logs (if they record the use of TLS at all) will record
the ciphersuite used.  The administrator can make appropriate
conclusions:

    Oct 18 11:42:40 amnesiac postfix/smtp[29005]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.68.26]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 20 19:55:07 amnesiac postfix/smtp[21141]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.68.27]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 22 02:55:59 amnesiac postfix/smtp[8024]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.68.26]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 22 23:51:08 amnesiac postfix/smtp[26570]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.68.26]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 23 01:25:18 amnesiac postfix/smtp[18228]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[64.233.171.26]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 23 04:53:38 amnesiac postfix/smtp[20459]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[64.233.171.27]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 23 21:05:20 amnesiac postfix/smtp[29828]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[64.233.171.26]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 24 03:23:26 amnesiac postfix/smtp[1541]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[64.233.171.27]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)

After all the fuss about RC4, I've taken a minute to  add a
destination-specific TLS policy for gmail.com:

    tls-policy:
	gmail.com encrypt exclude=RC4

# postmap tls-policy

    main.cf:
	indexed = ${default_database_type}:${config_directory}/
	smtp_tls_policy_maps = ${indexed}tls-policy

Now I have:

    Oct 24 14:51:57 amnesiac postfix/smtp[10528]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.76.26]:25: TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)

No publically known RC4 attacks apply to MTA to MTA delivery without
SASL AUTH, but there we have it, after enabling server cipher order
preempt on my end, and disabling RC4 for Gmail, who can do better,
I am no longer seeing RC4 in my logs (still enabled for all other
destinations, no idea which ones are still running Exchange 2003).

-- 
	Viktor.


From nobody Fri Oct 24 08:49:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BB61A1A9E for ; Fri, 24 Oct 2014 08:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U92UTMi423o5 for ; Fri, 24 Oct 2014 08:49:33 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC671A1A72 for ; Fri, 24 Oct 2014 08:48:03 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 713EEF984; Fri, 24 Oct 2014 11:48:00 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 8D0331FF72; Fri, 24 Oct 2014 11:48:01 -0400 (EDT)
From: Daniel Kahn Gillmor 
To: Stephen Farrell , tls@ietf.org
In-Reply-To: <543870F9.3030800@cs.tcd.ie>
References: <20141010230128.29009.31779.idtracker@ietfa.amsl.com> <543870F9.3030800@cs.tcd.ie>
User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu)
Date: Fri, 24 Oct 2014 11:47:56 -0400
Message-ID: <874mutxydv.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QLArL8jA1rYOc7JyCDxH8MWEItI
Subject: Re: [TLS] TLS WG Interim Meeting, November 9, 2014
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 15:49:34 -0000

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri 2014-10-10 19:51:21 -0400, Stephen Farrell wrote:
> I think this is still a placeholder for now and the chairs will
> confirm details as they get feedback. This announcement goes out
> once the interim is approved, which needed to be done now so
> there was sufficient notice for folks.
>
> S.
>
> On 11/10/14 00:01, IESG Secretary wrote:
>> The TLS WG will hold an interim meeting in Honolulu prior to IETF 91=20
>> on Sunday, November 9, 2014.
>>=20
>> The chairs will post details with an agenda and a final location closer=
=20
>> to the meeting.
>>=20
>> Additional information will be announced on the TLS WG mailing list:
>> http://www.ietf.org/mail-archive/web/tls/current/maillist.html

If this is still a placeholder, it's getting quite late to make sure
this interim meeting happens.  Can we confirm that it's going to happen
on Sunday, November 9th?

   --dkg

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQJ8BAEBCgBmBQJUSnStXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcmc8P/0F9qErGKm379nx2XyK05cen
MJxFCbxyM85EgZQjXX4jKEtvMrMIgiHAcBYySUcuezbrVK/TyY6SSUHC3pAlcVBb
eEBb3Iv3Lz7sFNbdNky5oFiJ/KouXZTIKEc2gE9FVS1VVikHmdZP+DXbkJVJB2vK
URa5hJwpPAYByLYwmHBPbcmCw7ycxl93/GARDBw7yYGAu7XClFkM3m3wt5uP6TJr
DD7QKq/eQ52LeNUottcj9WN010xrvVI1lrqzfkmBhqh2SSKwKKxAwE+9ArlfyotP
I5gt8300n3pVJWiU5t1Rh8BNhjV4MY+gu5WiYdAE0NePLLlGKCKbCN/fJTBVe+bU
XdxrwXv3Cuq4g/eznSd/PLRICDMZ14BqHsV4Ik0Fr+Dki+GjTHYJDK4mBw6Xb9Zq
qqW3GsFrwGz8N3rUQgCmRpLZYmLQKw0LZ9QxvlMzmq9nXTVAmKq2YUEZtOFaZZbG
BQolVyvq0mIEiSVws1bXqeEjq0OmJkUdfCB5S56wV5QyGwan1IZxHqicNQt7sDBs
ZElUIa0aSim87VqpsNoIarT0c3o/DBHNq7IdfRKmtFBsVlmFUE/1ZErJJtOiTVwY
BL9Y5F72Xkie343Y2NxZLrIZO9AjuUANMalj4FFxrlCusw6C3agXqjbvXxZrStjO
AoyMXK97P7lHokc64MQD
=iK48
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri Oct 24 08:53:18 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4795D1A1B1C for ; Fri, 24 Oct 2014 08:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1beF_aBM3u6 for ; Fri, 24 Oct 2014 08:53:06 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3E20A1A1AF6 for ; Fri, 24 Oct 2014 08:52:58 -0700 (PDT)
Received: from [10.70.10.51] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id D489DF986; Fri, 24 Oct 2014 11:52:55 -0400 (EDT)
Message-ID: <544A75D6.2010804@fifthhorseman.net>
Date: Fri, 24 Oct 2014 11:52:54 -0400
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0
MIME-Version: 1.0
To: Stephen Farrell , tls@ietf.org
References: <20141010230128.29009.31779.idtracker@ietfa.amsl.com> <543870F9.3030800@cs.tcd.ie> <874mutxydv.fsf@alice.fifthhorseman.net>
In-Reply-To: <874mutxydv.fsf@alice.fifthhorseman.net>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AV1QLsgOpBQ1LhlX8sqlR46M26sXv7UF0"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jf1UaW9-37HCcxZzHeasMnkZIsA
Subject: Re: [TLS] TLS WG Interim Meeting, November 9, 2014
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 15:53:11 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--AV1QLsgOpBQ1LhlX8sqlR46M26sXv7UF0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 10/24/2014 11:47 AM, Daniel Kahn Gillmor wrote:
> If this is still a placeholder, it's getting quite late to make sure
> this interim meeting happens.  Can we confirm that it's going to happen=

> on Sunday, November 9th?

In particular, i'm concerned that the plan for Sunday appears to
conflict with Sunday's:

  1300-1450 HST - Introduction to the Security Area

which i think is scheduled to include Sean Turner, one of the TLS WG chai=
rs:

 https://datatracker.ietf.org/meeting/91/agenda.html

	--dkg


--AV1QLsgOpBQ1LhlX8sqlR46M26sXv7UF0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJUSnXWXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcZu4QAIKQdwo4tFIvcJD1gmIlBdtl
TZ0gVFJbsftcE0/3Jrbpl969jQ5rzbxZ5T8nu1d1xmYyHb+HF2i74ZIB6jivg2Rf
pUHinACOY/dq2lb42DpGiBbE4dLOfaFGZl2Qla+NGEnxx/zTcenO83TxiPyHp1Wg
gcjCU9MDrc61+V6H6BL70+X5wcvafbRybaeLXCnKI3MP+rsNLqa3kxarTY+qmjgL
h4Yts7FNgklDqayY46F4rprfMMVUckzWAiTL+OJwN/jrqik7W0pIFQqP5LV3aSP0
RfO6HCXlG/hIo0wlxQJBvxnVqzFRWOq4lMO6bz5xdslzGiULeNuHBDXTBv7iWHb/
eiNOQMXyibeBX+y4WH+u4dwoPnVQubrR3EtrofAnfRCNbQwqKZ9zocMVD01S9fHS
UUOLnIpFsL7r+tp+IirPN62O6gyTkn+8AyQFS7nOSD21Mnk7h4r6zy4muHXZpj0V
DiT7RDpv/uEMATFktr65DPozpxXXu0q6U/biQH+WAvQj7jhoFIWkay1pAVO0NXTk
qV0S0Mr1voni4oX45RP11nufTl5P5WpUevujMJPlkjFboRNJVHFT8p5nnvH8dmdB
JZSdDimDo15/yc4+dbu9z9m3bFYoBG6tfkEHiH2+yeg2D8diIK2UFhBa7myq6qJN
GOdrhAvPMBCj+ecOBdxe
=uk1/
-----END PGP SIGNATURE-----

--AV1QLsgOpBQ1LhlX8sqlR46M26sXv7UF0--


From nobody Fri Oct 24 08:54:19 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A941A00D6 for ; Fri, 24 Oct 2014 08:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYcJK5VKhMlu for ; Fri, 24 Oct 2014 08:54:16 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5CE1A1AA3 for ; Fri, 24 Oct 2014 08:54:14 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 846492AB04A; Fri, 24 Oct 2014 15:54:07 +0000 (UTC)
Date: Fri, 24 Oct 2014 15:54:07 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141024155407.GO19158@mournblade.imrryr.org>
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <20141024133728.GI19158@mournblade.imrryr.org> <544A5BB3.4000506@fifthhorseman.net> <20141024141215.GL19158@mournblade.imrryr.org> <544A680F.4080307@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <544A680F.4080307@fifthhorseman.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vO9AooMGwYG5Bnrt9K1DpGAsttY
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 15:54:18 -0000

On Fri, Oct 24, 2014 at 10:54:07AM -0400, Daniel Kahn Gillmor wrote:

> > Sorry, MTAs don't maintain SQLite databases with peer history.
> > There is no interactive user to override stale pinned information.
> 
> In the paragraphs above, you seem to be claiming both of:
> 
>  (a) MTAs keep state about their peers, so we can't do retries, and

Receiving anti-spam engines that track client "reputations" do.
Sending MTAs do not.

>  (b) MTAs don't keep state about their peers, so they can't remember
> what they've tried

Correct.  Asymmetry between client and server.

> My understanding as an MTA operator, is that MTAs *do* keep state about
> their peers, and have (sometimes complex) logic about delivery choices,
> including on a per-destination or per-peer basis.  Whether that state is
> an an SQLite database or not, i don't really care.

I am not familiar with any TLS policy pinning capabilities in Exim,
Postfix, Sendmail or Qmail.

> I agree that it's all "too much code", and i'd love to have a nice
> simple clean TLS-only (and good-ciphers-only) MTA that has no fallback
> logic.  But that's not going to cut it if we want to interop in today's
> world, and if we prioritize delivery over confidentiality and integrity
> (which i understand is the traditional prioritization for MTA operators,
> and i do it myself).

Unless this WG goes out of its way to break opportunistic TLS, it
is working just fine today. :-)  None of the MTAs listed above have
multi-stage TLS fallback.  TLS either works out of the box or is
not used (cleartext fallback or transmission failure).

> I also understand that suggesting this behavior without a patch can be
> frustrating to MTA developers -- i'm sorry that i don't have time to
> produce such a patch for Postfix now.

No problem, we would not accept the patch anyway.  Code complexity
leads to bugs.

> If we take the fallback approaches described above, and each fallback
> incurs a small delay, to avoid the peer reputation rejection scenarios,
> then mail being delivered to RC4-only peers would be minorly delayed
> upon first delivery, and mail being delivered to cleartext-only peers
> would be doubly delayed for first delivery.

Cleartext fallback is much simpler, and the problem is non-existent.
Simply allowing RC4 avoids the need for all the complex code you
suggest.

> You could also build in a decay of recorded peer state, so that messages
> would continue to retry with the best-known level of security for a
> given peer, but would eventually fall-back to weaker fallbacks before
> discarding the messages as non-deliverable.  In the event of a mail
> server that somehow loses better-than-RC4 ciphers or regresses to
> non-STARTTLS entirely, messages to that mailserver would be delayed but
> not lost.

Did I mention that code complexity leads to bugs?

> > Browser analogies and strategies work poorly or not at all when
> > misapplied to SMTP.
> 
> I wrote the entire original message thinking specifically about SMTP, fwiw.

And your approach is essentially a transplant of browser behaviour.
"This is not your browser's TLS".

-- 
	Viktor.


From nobody Fri Oct 24 09:50:44 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAF21A8728 for ; Fri, 24 Oct 2014 09:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ma9CqFJ7h1UB for ; Fri, 24 Oct 2014 09:50:38 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 15CB11A0177 for ; Fri, 24 Oct 2014 09:50:34 -0700 (PDT)
Received: from [10.70.10.51] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 796ADF984 for ; Fri, 24 Oct 2014 12:50:30 -0400 (EDT)
Message-ID: <544A834A.504@fifthhorseman.net>
Date: Fri, 24 Oct 2014 12:50:18 -0400
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0
MIME-Version: 1.0
To: tls@ietf.org
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <20141024133728.GI19158@mournblade.imrryr.org> <544A5BB3.4000506@fifthhorseman.net> <20141024141215.GL19158@mournblade.imrryr.org> <544A680F.4080307@fifthhorseman.net> <20141024155407.GO19158@mournblade.imrryr.org>
In-Reply-To: <20141024155407.GO19158@mournblade.imrryr.org>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hwOibkXoPlsmq1MTG0c1m8eEMbw14NlSp"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/i_5bgQ5Nn4FlnBiPbkgkouKamq0
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 16:50:40 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--hwOibkXoPlsmq1MTG0c1m8eEMbw14NlSp
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Victor--

On 10/24/2014 11:54 AM, Viktor Dukhovni wrote:
> I am not familiar with any TLS policy pinning capabilities in Exim,
> Postfix, Sendmail or Qmail.

I didn't say "pinning", but "keeping state", which may or may not
include pinning.  postfix's sending MTA at least keeps track of whether
a given destination is considered "unavailable", see for example the
counts tracked and applied by
default_destination_concurrency_failed_cohort_limit.

> Unless this WG goes out of its way to break opportunistic TLS, it
> is working just fine today. :-)  None of the MTAs listed above have
> multi-stage TLS fallback.  TLS either works out of the box or is
> not used (cleartext fallback or transmission failure).

To be clear: if the remote peer appears to offer STARTTLS in EHLO, and
the local system invokes it but the TLS handshake fails/is aborted, then
the local system tries again without doing STARTTLS even though it is
offered by the peer.  is this right?  or does a TLS handshake failure
count as a complete transmission failure?  if it's a transmission
failure comparable to a TCP RST, and the message is re-queued for later,
what is tried on the future reconnection?  even if it just directly
retries in the clear, this is a "fallback dance" of a sort.

>> I also understand that suggesting this behavior without a patch can be=

>> frustrating to MTA developers -- i'm sorry that i don't have time to
>> produce such a patch for Postfix now.
>=20
> No problem, we would not accept the patch anyway.  Code complexity
> leads to bugs.

Yes, it would be simpler to just require TLS, but we're already past
that point if we're prioritizing deliverability over security while
trying to provide some security anyway.

>> If we take the fallback approaches described above, and each fallback
>> incurs a small delay, to avoid the peer reputation rejection scenarios=
,
>> then mail being delivered to RC4-only peers would be minorly delayed
>> upon first delivery, and mail being delivered to cleartext-only peers
>> would be doubly delayed for first delivery.
>=20
> Cleartext fallback is much simpler, and the problem is non-existent.
> Simply allowing RC4 avoids the need for all the complex code you
> suggest.

As does simply not allowing RC4.  If we're taking measures to
accommodate broken/out-of-date/poorly-implemented peers, it's worth
thinking about how to scope those accommodations to have minimal
negative effect on better-implemented and more-capable peers, as well as
on how to work around specific forms of misconfiguration that happen to
be prevalent.

>>> Browser analogies and strategies work poorly or not at all when
>>> misapplied to SMTP.
>>
>> I wrote the entire original message thinking specifically about SMTP, =
fwiw.
>=20
> And your approach is essentially a transplant of browser behaviour.
> "This is not your browser's TLS".

It is actually not browser behavior.  Browsers today appear to fall back
based on the TLS version (see the FALLBACK_SCSV discussion here), but
not on ciphersuite choices or other features.  Popular browsers are in
the process of working up the courage to not to fall back to SSLv3
anymore, fwiw.  These are different modes of fallback operation than
we've been discussing, and they are distinct (and have different goals
and behaviors) from any sort of OS logic (they refuse to fall back to
cleartext, among other things).

TLS as a protocol is specified such that correct peers should never need
to do any kind of fallback dance, even if their implementations support
different versions.  Browsers layer in a fallback dance on top of TLS
(which sometimes makes bugs like POODLE exploitable) because they (like
MTAs) also value connectivity at least as much as security.

But a browser fallback dance and an MTA fallback dance are different,
and have subtly different features.

Other TLS applications (like Submission or IMAPS) have no fallback dance
at all, because of the nature of the pre-established relationship
between communication partners).

Perhaps the argument is that the MTA fallback dance, since it can be
forced ultimately to cleartext by a sufficiently motivated active
attacker anyway, should be *simpler* than the browser fallback dance,
and shouldn't make as many accommodations or require as much state and
complexity to implement.  I'm not sure i buy it, but if that's the
argument, it's worth making it explicitly.

Regards,

	--dkg


--hwOibkXoPlsmq1MTG0c1m8eEMbw14NlSp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJUSoNKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpc5voQAKJw3XddTVwwmJ7VfSU4a/Sr
V2bcF/KVImGoKAFlSDA23GipuLsAl9b7Bm5jx+pSZpO+z0L+rBbOOs3+2cb/fQK5
mqGoku6sxvLUdVUacLpaax9EeeTy6WZ/YbNg+XZbDIwLdHgwCoLJAboK8RPdcyuX
Hrd1KL39Pk6ad8JNGvOSmPeT4loXaiz4ot4n4IHoWUNzr3TCXX4+07OXacRG3W69
iZAz3BcALqNc5ITZ7jsnQ6lWFpvoAF5hZq6FuXa9D15HChE72NCwTTlRgkS4gtoS
kOiCee2XXSAsOb4P1XxuGhfu2Sg8l85Jvtkfc6yWcBr88BaMYoy35lMa3TgGNkKy
TE2yN5IiKTXt6jOfLay/HCtlQJUccPqaAVekKAEx8vu3+SXVdYdxUtzFycoWwv7d
n8wCQXGc+WMjQfmUdA4/Rsyssa7VJ4GbWc8JN6G7VLEYYlgMe4SQbDP3pJYF/ZUf
ZQcgVA2p7/JO6qUXXld3W1ncEZqBzyhc9N0tfbUTjzlEpbv5GHlKvyavijNY5GMk
W2mkuMYFfKB1oJzTvk9iLr1BW9U2kfIuCsUIeMv8hFXwkQ0eRETTfW7NGzLQXgX/
1gLY+wf0XMyocNHwecuUn6Vs4grsKbBFyhXgNgl9oCBqFyHZecFy64D0TSWqWSyF
Y4nMd93hmIOfoifdUy9N
=yVmF
-----END PGP SIGNATURE-----

--hwOibkXoPlsmq1MTG0c1m8eEMbw14NlSp--


From nobody Fri Oct 24 09:53:51 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A371A88F4 for ; Fri, 24 Oct 2014 09:53:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 507rtpgz5eTp for ; Fri, 24 Oct 2014 09:53:42 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8DD1A87CC for ; Fri, 24 Oct 2014 09:51:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=ZFdGCU9+PBMa2Y6qhJzO9NElcwqsCIek16KswhhMaJI=;  b=i5UN+A7oqwHaIty3GSuDnE95T4jYV+wUbXdq5swPGfq6mwwT7/FD8RVGiOaNUFfFlcx0OcP+uvA4ReqfvYyEH+jiFN1OkfsWpOHClQcBZZJUldo5WFdxVOyuPNkJSCNHlUzdOiT8hz76/jVVfKUPYBOOqKDAqFy95GAdlvXEwng=;
Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xhi5f-0002bc-7f; Fri, 24 Oct 2014 18:51:51 +0200
Message-ID: <544A83AB.80901@polarssl.org>
Date: Fri, 24 Oct 2014 18:51:55 +0200
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Peter Gutmann ,  "dkg@fifthhorseman.net" , "tls@ietf.org" 
References: <9A043F3CF02CD34C8E74AC1594475C739B9D7684@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9D7684@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.161.199.191
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/X4wzdSC4yhYTRf-77ZQHY0SieQE
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 16:53:44 -0000

On 24/10/2014 13:32, Peter Gutmann wrote:
> Shorter groups are still required for embedded devices. You're not "blessing"
> them, you're just giving people the option to use them.

People already have the option to use arbitrary groups, and it itsn't going away
with this draft. This draft is about improving security, I don't think it makes
sense to standardise shorter groups in this context.

Manuel.

PS: besides, I agree that constrained devices had better use ECC anyway.


From nobody Fri Oct 24 10:05:55 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DEA1A88B7 for ; Fri, 24 Oct 2014 10:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlDU0xsa6aki for ; Fri, 24 Oct 2014 10:05:43 -0700 (PDT)
Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35971A8854 for ; Fri, 24 Oct 2014 09:58:55 -0700 (PDT)
Received: by mail-qa0-f45.google.com with SMTP id dc16so1226232qab.4 for ; Fri, 24 Oct 2014 09:58:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YfsWtwMTPZbhqkW3v6JytQHto07f2cGJHvbCaPDtE34=; b=OKwga2CTxzmQ2YD6nfx+f4mhHi4T3u2H564HrmWSjzIv9rej/Zblq9/QgY8IVnyQxw l09Y9mZTOtErafwbS/GNq5ZO3mUiztA0/3Og8cUm9D+gE2GoTwvCwdksmwkzxCRJblZp wGNYh2Rd/Rhpux872V6Wd6dZ++LnTn+sG9zlmTYqLifsVw/zy9/ayqkXZtr46ymHrbiS W3iESBsZo0rGG2eiFeQ9RlicelbDI2wxAYAVB8k+bZVvBaGX1sEvUcRwBK46hHQNxHQM qggL+rKKXKYJ8lbBUO7y8bSBypJObFMK6RjdiNQpkiLcqpf+sdCDA0od6vgKDVQyO7RW Q+gg==
X-Gm-Message-State: ALoCoQk328kU4CZdo2OfrrfbBIy6bJkDXCIbzv0zVUUBqAB/CyeHSwMD7TF/97fBsfnTZ9GiAchX
MIME-Version: 1.0
X-Received: by 10.224.171.194 with SMTP id i2mr7704285qaz.59.1414169934820; Fri, 24 Oct 2014 09:58:54 -0700 (PDT)
Received: by 10.96.166.35 with HTTP; Fri, 24 Oct 2014 09:58:54 -0700 (PDT)
X-Originating-IP: [2601:8:b300:a5:7c04:f406:8425:71d0]
In-Reply-To: <1730049.IgUL0REWQP@pintsize.usersys.redhat.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <1730049.IgUL0REWQP@pintsize.usersys.redhat.com>
Date: Fri, 24 Oct 2014 09:58:54 -0700
Message-ID: 
From: Joseph Salowey 
To: Hubert Kario 
Content-Type: multipart/alternative; boundary=001a11c2b2769e0e8605062e18b4
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pcUY6LwXYJO8Pa1BBdOdOL8cUzs
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 17:05:46 -0000

--001a11c2b2769e0e8605062e18b4
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 24, 2014 at 3:50 AM, Hubert Kario  wrote:

> On Thursday 23 October 2014 19:21:08 Richard Fussenegger wrote:
> > On 10/23/2014 4:03 PM, Hubert Kario wrote:
> > > While it may negotiate AES-256 (because it wants to interoperate with
> > > clients that are configured to not to present weaker ciphers), doesn't
> > > mean that it as a whole is configured to the 256 bit level of
> > > security. With TLS1.2 it may sign the (EC)DHE parameters using SHA-1,
> > > it may use RSA key exchange using only 2048 bit keys, it may be just a
> > > local proxy server that is hard coded to connect using AES-128 with
> > > the backed servers over open Internet. Yes, server should encrypt the
> > > tickets with as strong algorithm as its most secure cipher, but there
> > > are many situations where it's not necessary. "MUST" is certainly not
> > > applicable.
> >
> > Those are good and valid arguments for a RECOMMENDED regarding session
> > ticket/token key algorithms or simply dropping one word and uppercasing
> > another does the trick (?):
>
> yes, I agree.
>
> >
> > https://tools.ietf.org/html/rfc5077#section-5.5
> >
> > >    o  The keys and cryptographic protection algorithms should be at
> > >
> > >       least 128 bits in strength.  Some ciphersuites and applications
> > >
> > > -     may require cryptographic protection greater than 128 bits in
> > > +     REQUIRE cryptographic protection greater than 128 bits in
> > >
> > >       strength.
> >
> > But the MUST regarding key rotation, key discarding, and key count hard
> > limits is still appropriate in my opinion because PFS is a MUST in TLS
> > 1.3 (unless this has changed and I didn't read about it).
>
> Yes, while a large key size is recommended ("SHOULD"), a frequent key
> rotation
> (in order of days) is a "MUST" with shorter time scales recommended, given
> other parts of TLS 1.3.
>
>
[Joe] Personally, I don't think that PFS is a MUST for session resumption.
  I think an implementation can attempt to provide PFS like behavior, but
if one is really interested in PFS I think the full handshake is the way to
go.

I'm a bit concerned that we're going down the path of trying to mandate a
particular implementation.  I think we have the following areas under
discussion:

1.  Hard RFC 2119 requirements for things that are verifiable.  For
example, perhaps you would want to make sure that the client could request
the server issue a new ticket (the client can actually verify that the
ticket is different).

2.  Strong guidelines for the ticket and key management.  RFC 5077 has some
of these, they can be improved upon.  These would not necessarily be RFC
2119 language.

3.  Implementation guidance for ticket and key management.  Again RFC 5077
has some of this, but it can be improved upon.

I think we should be focusing first on 1 because it is normative and
affects interop.  2 is also important, but it should not force a particular
implementation.   3 is useful, but I do not think it should be normative
and I think it may be difficult to come to consensus on what the guidance
should be.  A discussion on 3 may help us with 1 and 2, but I think its a
secondary part of the discussion.

I want to make sure we have a clear understanding of 1 and 2.

--
> Regards,
> Hubert Kario
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a11c2b2769e0e8605062e18b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Oct 24, 2014 at 3:50 AM, Hubert Kario <hkario@redhat.com&g=
t; wrote:
On Thursday 23 Oct=
ober 2014 19:21:08 Richard Fussenegger wrote:

> On 10/23/2014 4:03 PM, Hubert Kario wrote:

> > While it may negotiate AES-256 (because it wants to interoperate =
with

> > clients that are configured to not to present weaker ciphers), do=
esn't

> > mean that it as a whole is configured to the 256 bit level of

> > security. With TLS1.2 it may sign the (EC)DHE parameters using SH=
A-1,

> > it may use RSA key exchange using only 2048 bit keys, it may be j=
ust a

> > local proxy server that is hard coded to connect using AES-128 wi=
th

> > the backed servers over open Internet. Yes, server should encrypt=
 the

> > tickets with as strong algorithm as its most secure cipher, but t=
here

> > are many situations where it's not necessary. "MUST"=
; is certainly not

> > applicable.

>

> Those are good and valid arguments for a RECOMMENDED regarding session=


> ticket/token key algorithms or simply dropping one word and uppercasin=
g

> another does the trick (?):



yes, I agree.



>

> https://tools.ietf.org/html/rfc5077#section-5.5

>

> >=C2=A0 =C2=A0 o=C2=A0 The keys and cryptographic protection algori=
thms should be at

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0least 128 bits in strength.=C2=A0 Some =
ciphersuites and applications

> >

> > -=C2=A0 =C2=A0 =C2=A0may require cryptographic protection greater=
 than 128 bits in

> > +=C2=A0 =C2=A0 =C2=A0REQUIRE cryptographic protection greater tha=
n 128 bits in

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0strength.

>

> But the MUST regarding key rotation, key discarding, and key count har=
d

> limits is still appropriate in my opinion because PFS is a MUST in TLS=


> 1.3 (unless this has changed and I didn't read about it).



Yes, while a large key size is recommended ("SHOULD"), a f=
requent key rotation

(in order of days) is a "MUST" with shorter time scales recommend=
ed, given

other parts of TLS 1.3.




[Joe] Personally=
, I don't think that PFS is a MUST for session resumption. =C2=A0 I thi=
nk an implementation can attempt to provide PFS like behavior, but if one i=
s really interested in PFS I think the full handshake is the way to go. =C2=
=A0

I'm a bit concerned that we're going d=
own the path of trying to mandate a particular implementation.=C2=A0 I thin=
k we have the following areas under discussion:

1.=
=C2=A0 Hard RFC 2119 requirements for things that are verifiable.=C2=A0 For=
 example, perhaps you would want to make sure that the client could request=
 the server issue a new ticket (the client can actually verify that the tic=
ket is different).

2.=C2=A0 Strong guidelines for =
the ticket and key management.=C2=A0 RFC 5077 has some of these, they can b=
e improved upon.=C2=A0 These would not necessarily be RFC 2119 language.

3.=C2=A0 Implementation guidance for ticket and key =
management.=C2=A0 Again RFC 5077 has some of this, but it can be improved u=
pon. =C2=A0
=C2=A0
I think we should be focusing first =
on 1 because it is normative and affects interop. =C2=A02 is also important=
, but it should not force a particular implementation. =C2=A0 3 is useful, =
but I do not think it should be normative and I think it may be difficult t=
o come to consensus on what the guidance should be.=C2=A0 A discussion on 3=
 may help us with 1 and 2, but I think its a secondary part of the discussi=
on. =C2=A0

I want to make sure we have a clear und=
erstanding of 1 and 2.

<=
div>

--

Regards,

Hubert Kario



_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--001a11c2b2769e0e8605062e18b4--


From nobody Fri Oct 24 10:18:18 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40081A1B3C for ; Fri, 24 Oct 2014 10:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5FTJTSa1tJN for ; Fri, 24 Oct 2014 10:18:14 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FE91A87C6 for ; Fri, 24 Oct 2014 10:18:14 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9OHHwUq029707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 24 Oct 2014 13:17:58 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9OHHumg019700 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2014 13:17:58 -0400
From: Hubert Kario 
To: Joseph Salowey 
Date: Fri, 24 Oct 2014 19:17:56 +0200
Message-ID: <7731083.j7JnX2pS4Y@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <1730049.IgUL0REWQP@pintsize.usersys.redhat.com> 
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HlD6lgL4v0LZ0hLzkEO31aGU8f8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 17:18:17 -0000

On Friday 24 October 2014 09:58:54 Joseph Salowey wrote:
> On Fri, Oct 24, 2014 at 3:50 AM, Hubert Kario  wrote:
> > On Thursday 23 October 2014 19:21:08 Richard Fussenegger wrote:
> > > On 10/23/2014 4:03 PM, Hubert Kario wrote:
> > > > While it may negotiate AES-256 (because it wants to interoperate with
> > > > clients that are configured to not to present weaker ciphers), doesn't
> > > > mean that it as a whole is configured to the 256 bit level of
> > > > security. With TLS1.2 it may sign the (EC)DHE parameters using SHA-1,
> > > > it may use RSA key exchange using only 2048 bit keys, it may be just a
> > > > local proxy server that is hard coded to connect using AES-128 with
> > > > the backed servers over open Internet. Yes, server should encrypt the
> > > > tickets with as strong algorithm as its most secure cipher, but there
> > > > are many situations where it's not necessary. "MUST" is certainly not
> > > > applicable.
> > > 
> > > Those are good and valid arguments for a RECOMMENDED regarding session
> > > ticket/token key algorithms or simply dropping one word and uppercasing
> > 
> > > another does the trick (?):
> > yes, I agree.
> > 
> > > https://tools.ietf.org/html/rfc5077#section-5.5
> > > 
> > > >    o  The keys and cryptographic protection algorithms should be at
> > > >    
> > > >       least 128 bits in strength.  Some ciphersuites and applications
> > > > 
> > > > -     may require cryptographic protection greater than 128 bits in
> > > > +     REQUIRE cryptographic protection greater than 128 bits in
> > > > 
> > > >       strength.
> > > 
> > > But the MUST regarding key rotation, key discarding, and key count hard
> > > limits is still appropriate in my opinion because PFS is a MUST in TLS
> > > 1.3 (unless this has changed and I didn't read about it).
> > 
> > Yes, while a large key size is recommended ("SHOULD"), a frequent key
> > rotation
> > (in order of days) is a "MUST" with shorter time scales recommended, given
> > other parts of TLS 1.3.
> 
> [Joe] Personally, I don't think that PFS is a MUST for session resumption.
>   I think an implementation can attempt to provide PFS like behavior, but
> if one is really interested in PFS I think the full handshake is the way to
> go.
> 
> I'm a bit concerned that we're going down the path of trying to mandate a
> particular implementation.  I think we have the following areas under
> discussion:
> 
> 1.  Hard RFC 2119 requirements for things that are verifiable.  For
> example, perhaps you would want to make sure that the client could request
> the server issue a new ticket (the client can actually verify that the
> ticket is different).

We already have ticket lifetime hints and basically nobody sets them higher 
than 48h (>99%), vast majority limit to 24h(>96%)[1]. That's including servers 
that don't use tickets at all! Of servers that do enable tickets, over 70% 
leave them at a 300s default. Nearly half of servers don't enable them at all.

That clearly means that server administrators don't consider renegotiation of 
clients that connect less often than once a day to be a burden on servers...

> 2.  Strong guidelines for the ticket and key management.  RFC 5077 has some
> of these, they can be improved upon.  These would not necessarily be RFC
> 2119 language.

...so if the actual use agrees with theory, nearly no one will be negatively 
impacted if all the frameworks actually started to enforce those limits (not 
that I think this should, let alone will happen). As such, I don't see why we 
shouldn't use the RFC 2119 language.
 
> 3.  Implementation guidance for ticket and key management.  Again RFC 5077
> has some of this, but it can be improved upon.
> 
> I think we should be focusing first on 1 because it is normative and
> affects interop.  2 is also important, but it should not force a particular
> implementation.   3 is useful, but I do not think it should be normative
> and I think it may be difficult to come to consensus on what the guidance
> should be.  A discussion on 3 may help us with 1 and 2, but I think its a
> secondary part of the discussion.

As it was pointed out, proper key management of server is non-verifiable by 
client, it may only be verified by auditing. Definite language there does 
help.

 1 - https://securitypitfalls.wordpress.com/2014/09/29/scan-results-for-september-2014/

-- 
Regards,
Hubert Kario


From nobody Fri Oct 24 10:28:07 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368D31A1B3C for ; Fri, 24 Oct 2014 10:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aV8RJjHbdSfb for ; Fri, 24 Oct 2014 10:28:03 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD4D1A86F9 for ; Fri, 24 Oct 2014 10:28:01 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A337DF984 for ; Fri, 24 Oct 2014 13:27:59 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 8AE841FF32; Fri, 24 Oct 2014 13:27:45 -0400 (EDT)
From: Daniel Kahn Gillmor 
To: tls@ietf.org
In-Reply-To: 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <1730049.IgUL0REWQP@pintsize.usersys.redhat.com> 
User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu)
Date: Fri, 24 Oct 2014 13:27:41 -0400
Message-ID: <871tpxxtrm.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/A7Ioz7O-IGs1ke6vksRxMl1TctQ
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 17:28:04 -0000

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri 2014-10-24 12:58:54 -0400, Joseph Salowey wrote:
> [Joe] Personally, I don't think that PFS is a MUST for session resumption.
>   I think an implementation can attempt to provide PFS like behavior, but
> if one is really interested in PFS I think the full handshake is the way =
to
> go.

If we decide to merge session resumption with PSK as discussed at the
interim meeting, then deciding that session resumption doesn't get
forward secrecy means that forward secrecy wouldn't be an option with
PSK.

Today, we have several forward-secret PSK ciphersuites:

0 dkg@alice:~$ gnutls-cli --list --priority NORMAL:-KX-ALL:+DHE-PSK:+ECDHE-=
PSK:-SIGN-ALL
Cipher suites for NORMAL:-KX-ALL:+DHE-PSK:+ECDHE-PSK:-SIGN-ALL
TLS_DHE_PSK_AES_128_GCM_SHA256                    	0x00, 0xaa	TLS1.2
TLS_DHE_PSK_AES_256_GCM_SHA384                    	0x00, 0xab	TLS1.2
TLS_DHE_PSK_CAMELLIA_128_GCM_SHA256               	0xc0, 0x90	TLS1.2
TLS_DHE_PSK_CAMELLIA_256_GCM_SHA384               	0xc0, 0x91	TLS1.2
TLS_DHE_PSK_AES_128_CBC_SHA1                      	0x00, 0x90	SSL3.0
TLS_DHE_PSK_AES_128_CBC_SHA256                    	0x00, 0xb2	TLS1.0
TLS_DHE_PSK_AES_256_CBC_SHA1                      	0x00, 0x91	SSL3.0
TLS_DHE_PSK_AES_256_CBC_SHA384                    	0x00, 0xb3	TLS1.0
TLS_DHE_PSK_CAMELLIA_128_CBC_SHA256               	0xc0, 0x96	TLS1.0
TLS_DHE_PSK_CAMELLIA_256_CBC_SHA384               	0xc0, 0x97	TLS1.0
TLS_DHE_PSK_3DES_EDE_CBC_SHA1                     	0x00, 0x8f	SSL3.0
TLS_DHE_PSK_ARCFOUR_128_SHA1                      	0x00, 0x8e	SSL3.0
TLS_ECDHE_PSK_AES_128_CBC_SHA1                    	0xc0, 0x35	SSL3.0
TLS_ECDHE_PSK_AES_128_CBC_SHA256                  	0xc0, 0x37	TLS1.0
TLS_ECDHE_PSK_AES_256_CBC_SHA1                    	0xc0, 0x36	SSL3.0
TLS_ECDHE_PSK_AES_256_CBC_SHA384                  	0xc0, 0x38	TLS1.0
TLS_ECDHE_PSK_CAMELLIA_128_CBC_SHA256             	0xc0, 0x9a	TLS1.0
TLS_ECDHE_PSK_CAMELLIA_256_CBC_SHA384             	0xc0, 0x9b	TLS1.0
TLS_ECDHE_PSK_3DES_EDE_CBC_SHA1                   	0xc0, 0x34	SSL3.0
TLS_ECDHE_PSK_ARCFOUR_128_SHA1                    	0xc0, 0x33	SSL3.0

Certificate types: CTYPE-X.509
Protocols: VERS-TLS1.2, VERS-TLS1.1, VERS-TLS1.0, VERS-SSL3.0, VERS-DTLS1.2=
, VERS-DTLS1.0
Compression: COMP-NULL
Elliptic curves: CURVE-SECP192R1, CURVE-SECP224R1, CURVE-SECP256R1, CURVE-S=
ECP384R1, CURVE-SECP521R1
PK-signatures: none
0 dkg@alice:~$=20

It would be a shame to lose the ability to combine forward secrecy with
PSK.

        --dkg

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQJ8BAEBCgBmBQJUSowOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcUowP/A8koes/JEBz1D2CN5pjUksI
OUS0jAvx/22zwAlHtg9lXaJqkHn1GIYpnje7AQ21/ILJ9F4y6roKSi1OLvQw34ic
0nXGgMqb1UBE1IMLK5hP3dBk9kZGD6A4Zkj25gngMxPUb5XgmB/Pw47TyKqKcioi
fUByPX2cnDLnBQnvxiMgRWDhEtKx2LJGI5PHlDwK+IT89pu/fBecRa7YzDfcjdCJ
YUNpw567W2uHMz6lJqTZ+ZutjaQJVbA6lFgIaWgKXoGGa8YUexm26UNM63e77h63
eKJG5PVFil2EoOi5CtK0tlY4r+lC4sF67JJTHdKAO5a8I3VdciFxLWCbkj+0ewVm
H+Nw2QJ+jK8AvWkD9zEcOSP7HsnR8huSSt474tQjZmxjkHtEZZLPlj2RnXmN1DRL
mKtLHxhM/EVlYHH3RFWJf5QVHzTWz+Nd/nX9TDe644g07A6K4J5JAtwfEV0lJZn0
pBpOCrN6qUodT8BsofMrZzsrDmnec0a5wVDuJzKkP2jzSmMZIiRLj6DPH9MBpmWO
XEwXX4AZQ1d/VqZhtXTQQMqneCminZFSEkQlZTeJ1mdJAnDzezQrzYo4AR1gmyDY
3qWlbSjQ5Vv0ormRwXxcH7NIQlceqAkMFvYNaBxBg2W2DwIowfs5T/Z12G4j4Rh5
wVKU3NiCjJ1xqcwmxhVk
=Q9GC
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri Oct 24 11:23:42 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDDE1A1AD1 for ; Fri, 24 Oct 2014 11:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfoShEaTxNjB for ; Fri, 24 Oct 2014 11:23:37 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4601A0368 for ; Fri, 24 Oct 2014 11:23:37 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 882AC2AB109; Fri, 24 Oct 2014 18:23:35 +0000 (UTC)
Date: Fri, 24 Oct 2014 18:23:35 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141024182335.GQ19158@mournblade.imrryr.org>
References: <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <20141024133728.GI19158@mournblade.imrryr.org> <544A5BB3.4000506@fifthhorseman.net> <20141024141215.GL19158@mournblade.imrryr.org> <544A680F.4080307@fifthhorseman.net> <20141024155407.GO19158@mournblade.imrryr.org> <544A834A.504@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <544A834A.504@fifthhorseman.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UohXrz_htnfnKp1W6FaKAUVFFhw
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 18:23:40 -0000

On Fri, Oct 24, 2014 at 12:50:18PM -0400, Daniel Kahn Gillmor wrote:

> > I am not familiar with any TLS policy pinning capabilities in Exim,
> > Postfix, Sendmail or Qmail.
> 
> I didn't say "pinning", but "keeping state", which may or may not
> include pinning.  

I meant pinning in a broad sense that includes storing TLS
capabilities.

> Postfix's sending MTA at least keeps track of whether
> a given destination is considered "unavailable", see for example the
> counts tracked and applied by
> default_destination_concurrency_failed_cohort_limit.

[ Deep-dives into Postfix designs here are not going to be productive
  direction.  I will not respond to further attempts to sell me on the
  merits of complex schemes for MTA. ]

As the instigator of that algorithm, I am well aware of its design.
This is not persistent state.  It is flushed as soon as there are
there no more messages in the queue for the destination in question.
For dead destinations the zombie state lives for a short time in
the queue manager's memory until a timer expires.

This does not leave any room for persisting state beyond the lifetime
of a stream of back to back messages.  Nor does the queue manager
store any state about MX hosts, that would be up the SMTP delivery
agent.

> > Unless this WG goes out of its way to break opportunistic TLS, it
> > is working just fine today. :-)  None of the MTAs listed above have
> > multi-stage TLS fallback.  TLS either works out of the box or is
> > not used (cleartext fallback or transmission failure).
> 
> To be clear: if the remote peer appears to offer STARTTLS in EHLO, and
> the local system invokes it but the TLS handshake fails/is aborted, then
> the local system tries again without doing STARTTLS even though it is
> offered by the peer.  is this right?

It is implementation dependent.  Postfix will typically try in the
clear, with some of the most recent versions typically after the
message is tried and fails at any other MX hosts.  Sendmail does
not retry in the clear after STARTTLS fails, the message stays in
queue unless some other MX host is less broken.

> or does a TLS handshake failure
> count as a complete transmission failure? 

Yes in Sendmail.

> if it's a transmission
> failure comparable to a TCP RST, and the message is re-queued for later,
> what is tried on the future reconnection?

STARTTLS again with Sendmail.  With Postfix generally STARTTLS,
but on a second failure by default cleartext in all versions.  We're
thinking of adding controls that optionally disable this fallback and
allow users to chooose the Sendmail behaviour.

> even if it just directly
> retries in the clear, this is a "fallback dance" of a sort.

I already said there's fallback (to cleartext from TLS).  There is
not and will not be cipher suite or protocol fallback.

> Yes, it would be simpler to just require TLS, but we're already past
> that point if we're prioritizing deliverability over security while
> trying to provide some security anyway.

The fallback mechanism will be kept as simple as possible.  That
means no multiple attempts with different variants of the TLS
settings.  If that TLS handshake fails, mail is sent in the clear
or not sent.  If some TLS feature choices are error prone, they
are not used.

Thus, for example, RC4 will not by default be disabled for some
time.  If TLS 1.3 will prove to have interop issues, it will be
initially disabled until these are resolved.  And so on.

Opportunistic TLS will avoid bleeding-edge settings, and will stick
to what is known to work reliably (be it "less optimally" in some
sense).

> > Cleartext fallback is much simpler, and the problem is non-existent.
> > Simply allowing RC4 avoids the need for all the complex code you
> > suggest.
> 
> As does simply not allowing RC4.  If we're taking measures to
> accommodate broken/out-of-date/poorly-implemented peers, it's worth
> thinking about how to scope those accommodations to have minimal
> negative effect on better-implemented and more-capable peers, as well as
> on how to work around specific forms of misconfiguration that happen to
> be prevalent.

This non-problem is not worth the time we're spending on it.

> Perhaps the argument is that the MTA fallback dance, since it can be
> forced ultimately to cleartext by a sufficiently motivated active
> attacker anyway, should be *simpler* than the browser fallback dance,
> and shouldn't make as many accommodations or require as much state and
> complexity to implement.  I'm not sure i buy it, but if that's the
> argument, it's worth making it explicitly.

That's a good part of the argument, opportunistic TLS is icing on
the cake.  Mostly good neighbourliness for the benefit of the
ecosystem rather than a specific desire to protect a paricular
message.  Therefore, the mechanisms used need to be simple and
reliable.

With opportunistic DANE TLS, when usable TLSA RRs are published,
some SMTP clients allow remote servers to signal a requirement for
stronger protection (in a downgrade-resistant manner).  Here the
picture changes, fallback is not enabled by default (to either
cleartext or unauthenticated encryption) and stronger ciphersuites
are required.  In this case RC4 might reasonably be excluded for
such peers.  It am not expecting too many RC4-only peers with
published TLSA records.

We should stop spamming the list...  This is largely off topic
here.

-- 
	VIktor.


From nobody Fri Oct 24 11:38:49 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D2C1A1B3B for ; Fri, 24 Oct 2014 11:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19S0XjZ43n8z for ; Fri, 24 Oct 2014 11:38:39 -0700 (PDT)
Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE2B1A026C for ; Fri, 24 Oct 2014 11:38:39 -0700 (PDT)
Received: by mail-qa0-f49.google.com with SMTP id f12so1339738qad.22 for ; Fri, 24 Oct 2014 11:38:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m96o8BNUULr50bYtQfmDyp14iAwP0rGNTFTFDusNevk=; b=Nns5WcHGvd2Ejp9y4d/CzdF7RIB8XMl6/IPmyYlzxMiJHzuwExOGg8q5FGNtnWlFBF SYZeLE/6khMEGqrVhRnGo761Z2XY0TadcMn+o1n01JQmuGk5BH0gbaELsbuYFkyGyKUX kNMRZwKhWxnYqb4CSL0d+Uequhyro1BBFEcTGLCl8fxcGnYo6XQq8M2hkUwHvsxPJOsR pfhANLZr2kLpsjladJpmVzAnhqlUJvi1wCozlfetrWIPKYu59jbhgisv6Bn8VJLP/+oy IEZnQ9TlQHz0tn/R/qA13lg1Iu8Ma1IQeK9GpfGabUKKc+jpTDAoTDikgr0bCdy/8voB c2YA==
X-Gm-Message-State: ALoCoQnHqByGsyqDxn8fDX0ZX+DMml4h3pu30aRxEqhFX6vLN13lIYWNQ9F8YjUAHg3QbJoUViH2
MIME-Version: 1.0
X-Received: by 10.140.93.18 with SMTP id c18mr8142117qge.58.1414175917745; Fri, 24 Oct 2014 11:38:37 -0700 (PDT)
Received: by 10.96.166.35 with HTTP; Fri, 24 Oct 2014 11:38:37 -0700 (PDT)
X-Originating-IP: [67.168.161.122]
In-Reply-To: <544A75D6.2010804@fifthhorseman.net>
References: <20141010230128.29009.31779.idtracker@ietfa.amsl.com> <543870F9.3030800@cs.tcd.ie> <874mutxydv.fsf@alice.fifthhorseman.net> <544A75D6.2010804@fifthhorseman.net>
Date: Fri, 24 Oct 2014 11:38:37 -0700
Message-ID: 
From: Joseph Salowey 
To: Daniel Kahn Gillmor 
Content-Type: multipart/alternative; boundary=001a113a48743a5ecb05062f7d9f
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pUPA1KpXhS3y-P8nexzDu5NxhOs
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS WG Interim Meeting, November 9, 2014
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 18:38:41 -0000

--001a113a48743a5ecb05062f7d9f
Content-Type: text/plain; charset=UTF-8

Yes, we are having the meeting and we have a meeting room reserved for the
time specified.  I will be at the meeting and will carver the time that
Sean has other commitments.

Cheers,

Joe

On Fri, Oct 24, 2014 at 8:52 AM, Daniel Kahn Gillmor 
wrote:

> On 10/24/2014 11:47 AM, Daniel Kahn Gillmor wrote:
> > If this is still a placeholder, it's getting quite late to make sure
> > this interim meeting happens.  Can we confirm that it's going to happen
> > on Sunday, November 9th?
>
> In particular, i'm concerned that the plan for Sunday appears to
> conflict with Sunday's:
>
>   1300-1450 HST - Introduction to the Security Area
>
> which i think is scheduled to include Sean Turner, one of the TLS WG
> chairs:
>
>  https://datatracker.ietf.org/meeting/91/agenda.html
>
>         --dkg
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a113a48743a5ecb05062f7d9f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Yes, we are having the meeting and we have a meeting room =
reserved for the time specified.=C2=A0 I will be at the meeting and will ca=
rver the time that Sean has other commitments. =C2=A0=C2=A0

<=
div>Cheers,

Joe

On Fri, Oct 24, 2014 at 8:52 AM, Daniel =
Kahn Gillmor <dkg@fifthhorseman.net> wrote:
On 10/24/2014 11:47 AM, Daniel Kahn =
Gillmor wrote:

> If this is still a placeholder, it's getting quite late to make su=
re

> this interim meeting happens.=C2=A0 Can we confirm that it's going=
 to happen

> on Sunday, November 9th?



In particular, i'm concerned that the plan for Sunday appears to=


conflict with Sunday's:



=C2=A0 1300-1450 HST - Introduction to the Security Area



which i think is scheduled to include Sean Turner, one of the TLS WG chairs=
:



=C2=A0https://datatracker.ietf.org/meeting/91/agenda.html



=C2=A0 =C2=A0 =C2=A0 =C2=A0 --dkg




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--001a113a48743a5ecb05062f7d9f--


From nobody Fri Oct 24 11:43:01 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F155F1A6FC8 for ; Fri, 24 Oct 2014 11:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_UFb3YLf1JU for ; Fri, 24 Oct 2014 11:42:59 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A52091A6F98 for ; Fri, 24 Oct 2014 11:42:58 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 6B94720047B14 for ; Fri, 24 Oct 2014 11:42:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ZmgYWbO3XKUxxsPb2MIX XLU6B9c=; b=K3L94EkrqFH2iAe5EuziLZsqjCehdbDlTY5eQVoWxiVeyGo0GVZP oKANxPvmqKwFKbG2rMD0TN/DfeJ7oTGXB0ZchUXEDrKYKkXNVkk9hpyMDHoM8Idb Z3/3gmckf6cw35B0NKt62LLMW1n32QatBLzduTFcyomEDM7Q83MMXio=
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id 206E320047B0E for ; Fri, 24 Oct 2014 11:42:57 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id q5so1893671wiv.4 for ; Fri, 24 Oct 2014 11:42:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.20.43 with SMTP id k11mr5992562wie.28.1414176176948; Fri, 24 Oct 2014 11:42:56 -0700 (PDT)
Received: by 10.216.32.135 with HTTP; Fri, 24 Oct 2014 11:42:56 -0700 (PDT)
In-Reply-To: <871tpxxtrm.fsf@alice.fifthhorseman.net>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <1730049.IgUL0REWQP@pintsize.usersys.redhat.com>  <871tpxxtrm.fsf@alice.fifthhorseman.net>
Date: Fri, 24 Oct 2014 13:42:56 -0500
Message-ID: 
From: Nico Williams 
To: Daniel Kahn Gillmor 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7t0Ihefs0jZFpgbjOCGWMHIqaqo
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 18:43:00 -0000

On Fri, Oct 24, 2014 at 12:27 PM, Daniel Kahn Gillmor
 wrote:
> On Fri 2014-10-24 12:58:54 -0400, Joseph Salowey wrote:
>> [Joe] Personally, I don't think that PFS is a MUST for session resumption.
>>   I think an implementation can attempt to provide PFS like behavior, but
>> if one is really interested in PFS I think the full handshake is the way to
>> go.
>
> If we decide to merge session resumption with PSK as discussed at the
> interim meeting, then deciding that session resumption doesn't get
> forward secrecy means that forward secrecy wouldn't be an option with
> PSK.

Why would that follow?  Joe says that PFS should not be REQUIRED for
resumption.  That doesn't mean it shouldn't be possible at all.

It's true that without merging PSK and resumption there would be no
need to support PFS in resumption handshakes: the whole point of
resumption is to reduce the number of PK key exchanges.  But it's not
obvious that a merger can't provide PFS as an option [that typically
just wouldn't be used in the resumption case].

Nico
--


From nobody Fri Oct 24 11:52:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295B11A8948 for ; Fri, 24 Oct 2014 11:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9fvPKaSY2QB for ; Fri, 24 Oct 2014 11:52:06 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3361A8822 for ; Fri, 24 Oct 2014 11:52:06 -0700 (PDT)
Received: from [10.70.10.51] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C031AF984; Fri, 24 Oct 2014 14:52:03 -0400 (EDT)
Message-ID: <544A9FC6.3080604@fifthhorseman.net>
Date: Fri, 24 Oct 2014 14:51:50 -0400
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0
MIME-Version: 1.0
To: Nico Williams 
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com>	<11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com>	<54493904.7010807@fussenegger.info>	<1730049.IgUL0REWQP@pintsize.usersys.redhat.com>		<871tpxxtrm.fsf@alice.fifthhorseman.net> 
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ggOjhXnRBk0EwaFjuSl9Iq06eCxXHuaBH"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/viAbG6C1NGDo-i_gXbez9Gpqsk4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 18:52:08 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ggOjhXnRBk0EwaFjuSl9Iq06eCxXHuaBH
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 10/24/2014 02:42 PM, Nico Williams wrote:
> On Fri, Oct 24, 2014 at 12:27 PM, Daniel Kahn Gillmor
>  wrote:
>> On Fri 2014-10-24 12:58:54 -0400, Joseph Salowey wrote:
>>> [Joe] Personally, I don't think that PFS is a MUST for session resump=
tion.
>>>   I think an implementation can attempt to provide PFS like behavior,=
 but
>>> if one is really interested in PFS I think the full handshake is the =
way to
>>> go.
>>
>> If we decide to merge session resumption with PSK as discussed at the
>> interim meeting, then deciding that session resumption doesn't get
>> forward secrecy means that forward secrecy wouldn't be an option with
>> PSK.
>=20
> Why would that follow?  Joe says that PFS should not be REQUIRED for
> resumption.  That doesn't mean it shouldn't be possible at all.

Sure, understood.  I just want to make sure that we retain the
possibility to do both PSK and session resumption with forward secrecy
if the peers want it, and not drop that combination on the floor.

	--dkg


--ggOjhXnRBk0EwaFjuSl9Iq06eCxXHuaBH
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJUSp/HXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcAgAQAKThObr2eZdkTEtazP2ziWva
Gmw+agrSFqfQdxwv9pvWeMKKQG6oNL6Rw7ZB6Ge1C3vDcAVtlT3SEhAbnL+OfaFd
1emaLTPm1Cadc7IB/Y97KQtavObXoARou9taPhCXkq5oz+XAg4/KoJVecQmyDT7M
+BrTQjqW/dA9N/mvBLTLPi653PIYVaMxj0XthpmtuF6+yvFJro4oVo3EkBKlnqTw
4kxJLHis3pqS0nogcbJuiQeg8Lwa9FTOyswyb3aPIAcJOfQj+vWmj7U4YPkhT4pG
4y5y+xF4Q3E54qwa31ir0YAowB+14c5getJ4SWVYcTt9075CUf0uVWzRG+cUuVEC
/OTiwjP1ShKa/MEdGUe0nuzJZNApgL+zEar5x8svZboxQ7nuMwxdfceEu//GmgF1
V8gw2hgKlX5yQtSj7xDjo9eZYxH1h+jIpGTxiBaFPdfolxTy8TWGkeNlXzBw0cCH
gHQB20/6YJAgjxOyWJXEcimmaFpVBTVmCWUsdo2USt/KVH8vUhIyqQ0Sx1zbySwz
DGIzlIk4CX+W5srIu5sz58swWRdY9PW0OYbKnttwWx+1Z2uhQR1HyqEQjF4sFM+i
8x4b63AF6r/SKtIaBpkxpx/XXsv2wUTls2xsWpnlsWtBw5lTOXU6fME/KRuXx5mB
HlgFD6j+9l69Y81otjmN
=uIIZ
-----END PGP SIGNATURE-----

--ggOjhXnRBk0EwaFjuSl9Iq06eCxXHuaBH--


From nobody Fri Oct 24 13:07:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3AF1A9107 for ; Fri, 24 Oct 2014 13:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHPN3qFobmH0 for ; Fri, 24 Oct 2014 13:07:05 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8803F1A1B21 for ; Fri, 24 Oct 2014 13:07:05 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id BBF5C33D0E1; Fri, 24 Oct 2014 20:07:04 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: tls@ietf.org
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <20141024133728.GI19158@mournblade.imrryr.org>
From: Geoffrey Keating 
Date: 24 Oct 2014 13:07:04 -0700
In-Reply-To: <20141024133728.GI19158@mournblade.imrryr.org>
Message-ID: 
Lines: 27
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2FCFJv5i0n8TIMkRXdfWdoj1rN0
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 20:07:09 -0000

Viktor Dukhovni  writes:

> When OS is a just-in-case "upgrade" from cleartext to unauthenticated
> encrypted communication, there is requirement for "considered good"
> algorithms.  The prime-directive is to not disrupt communication,
> only then do we try to encrypt if possible.
...
> Leaving a cipher suite out is only practical once it is no longer
> the best shared cipher with any peers.

Suppose 20% of hosts will use RC4 if it is offered, and 0.1% will
refuse a connection if RC4 is not offered.  Then by not offering RC4,
you are downgrading 0.1% to plaintext (assuming that's what happens)
and upgrading 20% to a secure cipher---in the short term.  I believe
that in itself is likely to be a win overall.

But, some won't go to plaintext, they will instead fail to deliver
mail.  This will cause them to be fixed.  Others will look for a
different relay host, which might support better encryption.  So maybe
it's 0.01%?

And, in the long term, it's more likely that an administrator will
notice the failed SSL attempts than connections which succeed but use
insecure ciphers.

So, I don't think what you're saying is a general rule, and I think it
doesn't apply in this case.


From nobody Fri Oct 24 13:14:53 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BACC1A19F9 for ; Fri, 24 Oct 2014 13:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZnEUDl6XFAk for ; Fri, 24 Oct 2014 13:14:50 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B0F1A0248 for ; Fri, 24 Oct 2014 13:14:50 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 27D6C33D0E1; Fri, 24 Oct 2014 20:14:50 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Peter Gutmann 
References: <9A043F3CF02CD34C8E74AC1594475C739B9D77B4@uxcn10-5.UoA.auckland.ac.nz>
From: Geoffrey Keating 
Date: 24 Oct 2014 13:14:50 -0700
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9D77B4@uxcn10-5.UoA.auckland.ac.nz>
Message-ID: 
Lines: 22
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tqg4dPC5jPQ3c6l3EaX74Y6tQEY
Cc: "" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 20:14:51 -0000

Peter Gutmann  writes:

> Alyssa Rowan  writes:
> 
> >No, it's blessing them even to list them. People will probably implement what
> >we specify.
> 
> So put in a note saying that use isn't recommended.  This isn't a bunch of
> Windows PCs with automatic update turned on, its unknown millions of embedded
> devices whose firmware is updated when the device falls apart and gets
> replaced, and for which you may get away with a small tweak from time to time
> but can't do any significant re-engineering once it's type-approved ("it
> works, don't touch it any more").

As a rule, devices whose firmware isn't/won't/can't be updated, won't
implement any new RFC, including this one.  So we are writing this RFC
for devices whose firmware will be updated and which are willing to
adopt 21st century technologies like ECDH or 2048-bit DH.

(And, for the record, I think it's insane to be even considering
standardising anything to do with 768-bit DH other than MUST NOT use
it!)


From nobody Fri Oct 24 13:21:15 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3D21A6F3C for ; Fri, 24 Oct 2014 13:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vpBKBjv8eB5 for ; Fri, 24 Oct 2014 13:21:11 -0700 (PDT)
Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA241A1A27 for ; Fri, 24 Oct 2014 13:21:10 -0700 (PDT)
Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-09v.sys.comcast.net with comcast id 78K81p0032PT3Qt018M9b9; Fri, 24 Oct 2014 20:21:09 +0000
Received: from [IPv6:::1] ([71.202.164.227]) by resomta-ch2-14v.sys.comcast.net with comcast id 78M81p00A4uhcbK018M814; Fri, 24 Oct 2014 20:21:09 +0000
Message-ID: <544AB4B4.2010305@brainhub.org>
Date: Fri, 24 Oct 2014 13:21:08 -0700
From: Andrey Jivsov 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Bodo Moeller , "tls@ietf.org" 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>	<5449E969.9000800@brainhub.org> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414182069; bh=tBhzzdfYKnYU2hIhTzQAHhybVgrU7Dwbq3QgSQgRMKY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ReBXB0eadXi6iltPn/VL84PCWtjVCzacRXQy0JlJUH9MGZWEcoTmJj3iQzjBLxpg5 7KqZ21WnQLdRxLvngC21Mz62ADvFYblrUT1X4TYieMfXTMsweKHjnCLsNcqj17Z5wB eP8Ts2EzvjbhkW/nq4vF7vGQ8rNslrIsznbQfvsm/N6eZOKZNOFLTiEoQ1HeameFaZ e6XCoTyT6btzUTGYcjafITB0VDKgZr+VxPdxHo1k5fPROsgH+xYlXMGwQgdPncC/3K zM6BB1wMQ/B+LOsc/jGYWhzxpD+uiB9JnTOAIzIk9/D0aCSiqjCFWE1V2G0tL92NfV z0lGvC0JsxcDw==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QBSZmjb0Z_gOQ3IiNwewRG2ETuk
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 20:21:14 -0000

On 10/24/2014 02:58 AM, Bodo Moeller wrote:
> Andrey Jivsov >:
>
>     Client decides to drop to TLS1.1 (due to network glitch, etc).
>     [...] The server MUST fail with inappropriate_fallback per sec 3.
>
>     Is it a good idea to reject a more secure protocol than the server
>     can possibly negotiate with this client?
>
>
> In this case, the connection really fails due to the network glitch. 
> If the client wasn't attempting fallback retries, it would similarly 
> fail. (This could happen independently of the cipher suites that the 
> server accepts.)

In this scenario the client would succeed with the same server if the 
server doesn't implement draft-ietf-tls-downgrade-scsv but will fail if 
the server implements draft-ietf-tls-downgrade-scsv-03. Interestingly, 
regardless of draft-ietf-tls-downgrade-scsv-03 implementation the 
negotiated ciphersuite will be the same (when the pair succeeds with the 
handshake, that is)


>
> In the kind of hypothetical scenario that you describe, it indeed 
> wouldn't cause a reduction in security to accept the connection 
> instead of failing, but optimizing for corner cases like this one 
> doesn't seem reasonable: it necessarily would make the mechanism more 
> complex overall.
>
> (The server behavior that you describe also would be really odd. The 
> CBC cipher suites are more broken in SSL 3.0 than in TLS 1.0, and more 
> broken in TLS 1.0 than in TLS 1.1. If the server *does* support one of 
> the newer protocol versions, why would it only support the most broken 
> incarnation of that cipher suite?
>

This configuration of the server may be driven by the logic that "we 
will use legacy algorithms (RC4, SHA1, etc) with legacy protocols (SSL*, 
TLS1.0) for legacy clients".

> Also note that in the *specific* hypothetical scenario that you 
> describe, the server actually would accept the fallback retry: you 
> said that TLS 1.0 is the highest protocol version supported by the 
> server; this is not higher than ClientHello.client_version in the TLS 
> 1.1 retry, so the server wouldn't reject.)

No, this is not what I was saying.

In my scenario the server supports TLS1.2 in general with some 
ciphersuites (and will support TLS1.3 in the future). The server is 
configured in a way that the ciphersuite that it can negotiate with the 
client requires SSLv3.

What does draft-ietf-tls-downgrade-scsv-03 want the server to do here: 
assume it's highest version is TLS1.2 or SSL 3.0?  I.e. is the max. 
version a static property on the server or dynamic based on ciphers in 
ClientHello?



From nobody Fri Oct 24 13:40:44 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74DD1A8A87 for ; Fri, 24 Oct 2014 13:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsLrJiNI1eIP for ; Fri, 24 Oct 2014 13:40:38 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B711A0231 for ; Fri, 24 Oct 2014 13:40:38 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0FB742AB2E7; Fri, 24 Oct 2014 20:40:37 +0000 (UTC)
Date: Fri, 24 Oct 2014 20:40:37 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141024204036.GR19158@mournblade.imrryr.org>
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <20141024133728.GI19158@mournblade.imrryr.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kNCIXYYMMIhghG_GKsTF7sl5Wx8
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 20:40:42 -0000

On Fri, Oct 24, 2014 at 01:07:04PM -0700, Geoffrey Keating wrote:

> Suppose 20% of hosts will use RC4 if it is offered, and 0.1% will
> refuse a connection if RC4 is not offered.  Then by not offering RC4,
> you are downgrading 0.1% to plaintext (assuming that's what happens)
> and upgrading 20% to a secure cipher---in the short term.  I believe
> that in itself is likely to be a win overall.

Well, the 20% "upgrade" is invisible and offers no immediate benefit,
while the 0.1% breakage causes people operational headaches, and
with sites they never specifically wanted encryption for.  They'll
then disable encryption for the site and forget they did that, so
the site is stuck at cleartext "forever".

Anyway, I think I've accepted the probability that RC4 will be a
MUST NOT, but that I'll simply have to ignore this for a few years.

-- 
	Viktor.


From nobody Fri Oct 24 13:44:54 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D92B1A0264 for ; Fri, 24 Oct 2014 13:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4obhi8sMnneC for ; Fri, 24 Oct 2014 13:44:50 -0700 (PDT)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id E16511A6EE9 for ; Fri, 24 Oct 2014 13:44:49 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id s9OKikFe000384 for ; Fri, 24 Oct 2014 16:44:48 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: "tls@ietf.org" 
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: AQHP7h2m71FI0rj2akmyZ4hzz+ycXpw8qMOAgABXIICAAWy3gIAASBaAgADRcoCAADM13YAAARiA
Date: Fri, 24 Oct 2014 20:44:47 +0000
Message-ID: 
References:  <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <20141024133728.GI19158@mournblade.imrryr.org>  <20141024204036.GR19158@mournblade.imrryr.org>
In-Reply-To: <20141024204036.GR19158@mournblade.imrryr.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-originating-ip: [172.26.148.57]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3497013881_400087"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28,  0.0.0000 definitions=2014-10-24_06:2014-10-24,2014-10-24,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410240177
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GzWSKuG5hawINtD72diIErAN2RE
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 20:44:52 -0000

--B_3497013881_400087
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

On 10/24/14, 16:40 , "Viktor Dukhovni"  wrote:

>Anyway, I think I've accepted the probability that RC4 will be a
>MUST NOT, but that I'll simply have to ignore this for a few years.

That=E2=80=99s my read on it too. I expect many to follow this approach.

--B_3497013881_400087
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP
8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5
pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi
ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj
akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu
ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T
eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m
1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2
BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ
NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk
u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK
PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y
MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4
YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C
PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2
QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D
1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB
kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB
BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE
VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ
BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ
iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw
7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8
c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt
DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX
X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE
BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET
MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG
SIb3DQEJBDEiBCB8KTKGw3IALP1/ol/Ekl/ivC+sxVfYwxmsl+PNUHuPdzAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEwMjQyMDQ0NDFaMA0GCSqGSIb3
DQEBAQUABIIBAHGo78xoPi11PtTc+096IO6hBkHot63KLmkJF5zNCU/mn7m1KYd57iVkzpCk
QRN+8+MUTQ3Ulto3FSZfXC6j4PdeLASlWYB6r++iriaB3aGXIY9Gt5e8q+InUGAojAVbVBxK
bPVYWhj7oXNkpz00o+9ZDbpBt6t9qy5LszBjNyCR7YGg+V63Wu+QLpuB6KcvZkjHe1b8Ql1A
QpVYHb7mMQWJC2JeFkl/Ya/aVgB2h7HuZ9WTfZESd6edaR8rECttiHBUVSZICX6J/Qkzjh0n
6iYUGWIl67EpcLRDz9W3Gp7J1LR5WXFVVWM0g57riDBjZ5dTFrilPMukJlcNjf/tMHQ=

--B_3497013881_400087--


From nobody Fri Oct 24 14:05:41 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8A71A6FE5 for ; Fri, 24 Oct 2014 14:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2t8ztjk21iMu for ; Fri, 24 Oct 2014 14:05:35 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684C31A6FEB for ; Fri, 24 Oct 2014 14:05:34 -0700 (PDT)
Message-ID: <544ABF21.6030005@akr.io>
Date: Fri, 24 Oct 2014 22:05:37 +0100
From: Alyssa Rowan 
MIME-Version: 1.0
To: "tls@ietf.org" 
References: <9A043F3CF02CD34C8E74AC1594475C739B9D77B4@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9D77B4@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/L_eY_FBD6EailybGrYS38a1LBRo
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 21:05:37 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 24/10/2014 15:55, Peter Gutmann wrote:

> Re-doing the crypto to implement and support ECC may happen in five
>  to ten years, if there's enough code space in the flash.

So, you want to use 768-bit groups… for five to ten years… yeah, I'm
not too comfortable with that.

>> No, it's blessing them even to list them. People will probably 
>> implement what we specify.
> So put in a note saying that use isn't recommended.

…or, you could not put it in.

Intentionally specifying something new, in a security-oriented RFC,
that by the way you absolutely shouldn't use because it's insecure,
seems a bit reckless to me.

> ("it works, don't touch it any more").

I think we really ought to be getting rid of skeletons in the closet,
not adding new ones - despite Hallowe'en being next week, and that
phrase being appropriately spine-chilling! ;)

(BTW: Lost, embedded devices; too small to use a 2048-bit group for…
some reason? RAM?; yet negotiate (768|1024|1536) DHE…

…wild guess here: RSA key signing this exchange is totally
minty-fresh? …and actually checked? With something that isn't MD5? And
the DHE keys aren't generated with 2 bits of entropy and a potato
because the $2.50 intern lunch budget didn't cover an RNG? )

>> 768 and 1024 are crackable today by any reasonably well-funded 
>> adversary with access to a chip fab, as you well know;
> ... who probably won't be using that capability to attack a power 
> meter, or a flow monitor

…or a centrifuge? ¬_¬

SCADA security - or lack thereof - is a very big problem. I don't
agree that specifying groups for future use that we _know_ are too
small, helps do anything but make it worse.

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUSr8hAAoJEOyEjtkWi2t6m38QAL2EZ53g3OJXyJiJyEfnDzx2
4SXY+MXL00ybwdzg2vO4zh8tDCRRZ9omP4X8nZzRndRVCMOk2gWPDa2ZZIw1unan
57ytBIsgS0X2bAW2GaJ2cs/+r6m/mQQy4bAjajhcEMmols1++48LtT0or+rucjpd
H0DFoNtVcpCqlM6mnLyMj5tsAB3gjL04Q2i0JUUA4KlKaK9uyyobLT3P+RluHjyP
DwU1OEjuacvdmmpliBSPROlGcG0nMU5nhHGJnCpE7yg6nlI2JXjUnJgtUdEyL8M3
O593w6CKN4kJ4HbPNo8vqQlpm/mUstfhSJ4pWiy8+EbxBFTICqZ9+l8ZsegDurJE
SrDAStQfDqpEW2kAe04cqL+yjfp8fB+akhwZXJkic5TBB+eRAPu1XHvHQkYRM69f
JPDCvLex0iwpM0LXU0dbpHtsuLvCnJzMcCdJYRSiN3Vs1FFcJMGI1gl6poCxIMMd
ieWfp8u/RfUkQKMPxMJgGIMWVdqED6xHqEFxF3tSW9noh603Oyz7ABP7K1Sm7wJ3
0X8YEKnycw8jHI0pAPCIKsREZ1s1o8AyhAZfxqoPG7tQIAO8of29W7fGD4II/bRT
7/wKsmUGGtQxGcnUPOAZvnzEg3zb6LEkVzUIcPCCjQlHOe6BVh/xaO0tjl1F/zQq
LitFwIoGpTwZEXhToa2x
=D0Ak
-----END PGP SIGNATURE-----


From nobody Fri Oct 24 15:30:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807801A040C for ; Fri, 24 Oct 2014 15:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level: 
X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuXBplgNT398 for ; Fri, 24 Oct 2014 15:30:05 -0700 (PDT)
Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1531A0861 for ; Fri, 24 Oct 2014 15:30:05 -0700 (PDT)
Received: from [10.20.30.90] (50-1-50-141.dsl.dynamic.fusionbroadband.com [50.1.50.141]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s9OMU3Zr000287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2014 15:30:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 50-1-50-141.dsl.dynamic.fusionbroadband.com [50.1.50.141] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Paul Hoffman 
In-Reply-To: 
Date: Fri, 24 Oct 2014 15:30:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20141010230128.29009.31779.idtracker@ietfa.amsl.com> <543870F9.3030800@cs.tcd.ie> <874mutxydv.fsf@alice.fifthhorseman.net> <544A75D6.2010804@fifthhorseman.net> 
To: Joseph Salowey 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mlI4MJwYpQgt4apcuq4u4e5v3K4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS WG Interim Meeting, November 9, 2014
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 22:30:07 -0000

On Oct 24, 2014, at 11:38 AM, Joseph Salowey  wrote:
>=20
> Yes, we are having the meeting and we have a meeting room reserved for =
the time specified.  I will be at the meeting and will carver the time =
that Sean has other commitments.  =20

Not to be too picky, but there was no "time specified". For those of us =
who need to plan around this, can you tell us soon what the actual time =
on that Sunday is?

--Paul Hoffman=


From nobody Fri Oct 24 15:44:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7196A1A19FE for ; Fri, 24 Oct 2014 15:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWLrQoSo0zZT for ; Fri, 24 Oct 2014 15:44:07 -0700 (PDT)
Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337AC1A1A24 for ; Fri, 24 Oct 2014 15:44:07 -0700 (PDT)
Received: by mail-qg0-f52.google.com with SMTP id q108so1678721qgd.25 for ; Fri, 24 Oct 2014 15:44:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=8GY4lI4ejZYVrUBWJVbqjF1SCrjA4TG2Tcg8lWXJvrA=; b=D0m9m5Ji9xj2dMOmUDaGLUTceC8TBm+OAEyZzSyyOj4Mkta47bjjC1toCvNXCW3xeq RN2MKJPvc0gvdYfrHkLlR16EOxIaU56LWr0W4bbh/ZsApvrJI65+EjRO7ui7NS9JX1MY O0sH/X9MDuQyochrSb5SyXRyqpO54xhLyPEC0Wuvrq8TCWoJOBlYb6mR9e+dA9ZdoUB3 tY7cvSz+V6bmaOr/4yoywBpNnawXgO7LFNdUX19TMlig2GedD4WeWT66H7CtoFYf/5vd 0wn6DwpBq9H2EoqyzZFp5OhPrIvEdD1TBZoqwTuMuFrUSSTbtHQUJVgVS0HBZ6DzBYK3 lJpA==
X-Gm-Message-State: ALoCoQleWzKwNV2hO/C1JXh4xpb8wnH5ov4N2JFT9y0xbq3kpfJErG6YFTFEBRPil+U44kMQeOtE
X-Received: by 10.224.79.146 with SMTP id p18mr10018021qak.67.1414190646334; Fri, 24 Oct 2014 15:44:06 -0700 (PDT)
Received: from zbox.pahtak.org (c-68-48-196-126.hsd1.md.comcast.net. [68.48.196.126]) by mx.google.com with ESMTPSA id n46sm5278546qgn.9.2014.10.24.15.44.04 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Oct 2014 15:44:05 -0700 (PDT)
Received: from mba.hsd1.md.comcast.net (router [192.168.1.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 64AB9AC28CC for ; Fri, 24 Oct 2014 18:44:03 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Stephen Checkoway 
In-Reply-To: <544ABF21.6030005@akr.io>
Date: Fri, 24 Oct 2014 18:44:03 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <257004DB-5165-43AF-9A62-9D3D981E6599@pahtak.org>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D77B4@uxcn10-5.UoA.auckland.ac.nz> <544ABF21.6030005@akr.io>
To: "tls@ietf.org" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eopNPKJ0LRMd9CBYLmYmtYaCpeY
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 22:44:09 -0000

The arguments against including small groups seem clear:

1. New things shouldn't be using small groups.
2. Old things that can't/won't be updated _won't be updated_ no matter =
what a new RFC says.
3. This doesn't prohibit arbitrary groups so anything that needs to keep =
using small groups can keep using small groups.

The argument for including small groups seems to be (and correct me if =
I've missed something):

Old things can't/won't be updated except for (maybe) small tweaks and =
this extension is a small tweak that would enable these devices to keep =
doing what they're already doing: using small groups.

Particularly in light of 3, I don't find the argument for including them =
compelling.

S

On Oct 24, 2014, at 5:05 PM, Alyssa Rowan  wrote:

> Signed PGP part
> On 24/10/2014 15:55, Peter Gutmann wrote:
>=20
> > Re-doing the crypto to implement and support ECC may happen in five
> >  to ten years, if there's enough code space in the flash.
>=20
> So, you want to use 768-bit groups=85 for five to ten years=85 yeah, =
I'm
> not too comfortable with that.
>=20
> >> No, it's blessing them even to list them. People will probably
> >> implement what we specify.
> > So put in a note saying that use isn't recommended.
>=20
> =85or, you could not put it in.
>=20
> Intentionally specifying something new, in a security-oriented RFC,
> that by the way you absolutely shouldn't use because it's insecure,
> seems a bit reckless to me.
>=20
> > ("it works, don't touch it any more").
>=20
> I think we really ought to be getting rid of skeletons in the closet,
> not adding new ones - despite Hallowe'en being next week, and that
> phrase being appropriately spine-chilling! ;)
>=20
> (BTW: Lost, embedded devices; too small to use a 2048-bit group for=85
> some reason? RAM?; yet negotiate (768|1024|1536) DHE=85
>=20
> =85wild guess here: RSA key signing this exchange is totally
> minty-fresh? =85and actually checked? With something that isn't MD5? =
And
> the DHE keys aren't generated with 2 bits of entropy and a potato
> because the $2.50 intern lunch budget didn't cover an RNG? )
>=20
> >> 768 and 1024 are crackable today by any reasonably well-funded
> >> adversary with access to a chip fab, as you well know;
> > ... who probably won't be using that capability to attack a power
> > meter, or a flow monitor
>=20
> =85or a centrifuge? =AC_=AC
>=20
> SCADA security - or lack thereof - is a very big problem. I don't
> agree that specifying groups for future use that we _know_ are too
> small, helps do anything but make it worse.
>=20
> --
> /akr
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--=20
Stephen Checkoway






From nobody Fri Oct 24 16:04:34 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBEE1A1B34 for ; Fri, 24 Oct 2014 16:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Encmy7UiMxpV for ; Fri, 24 Oct 2014 16:04:27 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9051A1AE1 for ; Fri, 24 Oct 2014 16:04:26 -0700 (PDT)
Received: from mail-yh0-f49.google.com (mail-yh0-f49.google.com [209.85.213.49]) by mrelayeu.kundenserver.de (node=mreue007) with ESMTP (Nemesis) id 0MTJZq-1XZWPu2KH8-00S4oI; Sat, 25 Oct 2014 01:04:24 +0200
Received: by mail-yh0-f49.google.com with SMTP id a41so1640368yho.8 for ; Fri, 24 Oct 2014 16:04:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.38.104 with SMTP id z68mr7579202yha.155.1414191863361; Fri, 24 Oct 2014 16:04:23 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Fri, 24 Oct 2014 16:04:23 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Fri, 24 Oct 2014 16:04:23 -0700 (PDT)
In-Reply-To: <544AB4B4.2010305@brainhub.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5449E969.9000800@brainhub.org>  <544AB4B4.2010305@brainhub.org>
Date: Sat, 25 Oct 2014 01:04:23 +0200
Message-ID: 
From: Bodo Moeller 
To: Andrey Jivsov 
Content-Type: multipart/alternative; boundary=047d7b672452a8f91d0506333325
X-Provags-ID: V02:K0:0qx/IpSZeO0Decz4+YmmE5VClj08ODLyiNLAIFZAjLw DTbeRumZgKhcyTKqZPug1RoZnAOXyhGPGClm0Rwp6ylVDxVCRd 87r4SLdvARXlYfB0wD+LUenTOW1+eNo1hH5QyJ/RvMt0cJ/Sor 7MI179OLK37MZZ9g1wGxeneHRvxzxp+YifiX/QortEJhsgNyWC OYRgTLaoclj6QMysci7UDYnBxHSaCndbojMSw5L6OLH5noA/8A phVx7YUSoxYiTKVtpP/R8CvcAVodKEAT1wRMw7zEYwm7mOQaB0 m2J1HUz+cEt/PCHKnLYrJSZqkzlE3m+UJrlxYY4vyqN0PzXuz/ 0wuaqZEzWeAn/jKafC4wFQprj/p6OoqLjBdaTHWekPkXOugXa6 pzLNSht6vurlw8bHiTPe6ApNa71b7pjlgAYWbbVQPR1uQ/M785 XaNAK
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NPknofOi5sDziBcXfML1cD5tgJk
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 23:04:30 -0000

--047d7b672452a8f91d0506333325
Content-Type: text/plain; charset=UTF-8

>> Also note that in the *specific* hypothetical scenario that you
describe, the server actually would accept the fallback retry: you said
that TLS 1.0 is the highest protocol version supported by the server; this
is not higher than ClientHello.client_version in the TLS 1.1 retry, so the
server wouldn't reject.)

> No, this is not what I was saying.

Yes, it is ("Let's assume that the server supports all protocols
SSL3.0-TLS1.0").  I gather that's not what you meant, though.

> In my scenario the server supports TLS1.2 in general with some
ciphersuites (and will support TLS1.3 in the future). The server is
configured in a way that the ciphersuite that it can negotiate with the
client requires SSLv3.
>
> What does draft-ietf-tls-downgrade-scsv-03 want the server to do here:
assume it's highest version is TLS1.2 or SSL 3.0?  I.e. is the max. version
a static property on the server or dynamic based on ciphers in ClientHello?

There's no -03 draft, but the current draft's implication should be clear:
the server compares protocol versions only and hence rejects. (Pretending
that the highest protocol version is SSL 3.0 wouldn't make sense.)

--047d7b672452a8f91d0506333325
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


>> Also note that in the *specific* hypothetical scena=
rio that you describe, the server actually would accept the fallback retry:=
 you said that TLS 1.0 is the highest protocol version supported by the ser=
ver; this is not higher than ClientHello.client_version in the TLS 1.1 retr=
y, so the server wouldn't reject.)


> No, this is not what I was saying.


Yes, it is ("Let's assume that the server supports =
all protocols SSL3.0-TLS1.0").=C2=A0 I gather that's not what you =
meant, though.


> In my scenario the server supports TLS1.2 in general wi=
th some ciphersuites (and will support TLS1.3 in the future). The server is=
 configured in a way that the ciphersuite that it can negotiate with the cl=
ient requires SSLv3.

>

> What does draft-ietf-tls-downgrade-scsv-03 want the server to do here:=
 assume it's highest version is TLS1.2 or SSL 3.0?=C2=A0 I.e. is the ma=
x. version a static property on the server or dynamic based on ciphers in C=
lientHello?


There's no -03 draft, but the current draft's implic=
ation should be clear: the server compares protocol versions only and hence=
 rejects. (Pretending that the highest protocol version is SSL 3.0 wouldn&#=
39;t make sense.)




--047d7b672452a8f91d0506333325--


From nobody Sat Oct 25 00:55:22 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522781A8547 for ; Sat, 25 Oct 2014 00:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Yfy5lf6GP_2 for ; Sat, 25 Oct 2014 00:55:18 -0700 (PDT)
Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C741A8029 for ; Sat, 25 Oct 2014 00:55:18 -0700 (PDT)
Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-06v.sys.comcast.net with comcast id 7KvB1p0012N9P4d01KvHNF; Sat, 25 Oct 2014 07:55:17 +0000
Received: from [192.168.1.2] ([71.202.164.227]) by resomta-ch2-13v.sys.comcast.net with comcast id 7KvG1p0074uhcbK01KvGw4; Sat, 25 Oct 2014 07:55:17 +0000
Message-ID: <544B5764.9020006@brainhub.org>
Date: Sat, 25 Oct 2014 00:55:16 -0700
From: Andrey Jivsov 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Bodo Moeller 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>	<5449E969.9000800@brainhub.org>		<544AB4B4.2010305@brainhub.org> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414223717; bh=xFQnxQLs5SY1TVH0NwqVBU1uY8SBKQ1tNw0ZsHdBni4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PwwcavHCd47g85K9/wLKiJNZNPTz6Oi4y7eB1jwkghe9vuUQ3qbQlcZda0xJyghPi /Nweqa31IUgQJNN78TPvQwSm/Ms2C9QSx2XZohPOFRKHjohAaTgPbQHcr4/MVBItgP Fzl3WPifVtLhZfW0MwjFn7WtequSHbdMS0sTFQbR4xp7ayj9kTuf0ymHvVPqj+Tdxu tCPjOP/PxqO9r4AUJCA8+Rdrb1ibNPE7A+0U4Oe6d9XyOztcPfpdps5hlCTOo03q8v s23dfrC7d22sBHoy/dQqC6UXXgnH9QU8TJyiodmKlxsRM/3WUQADDG/4PSbxhFd1HA pszPLCGCpRqIw==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/52QvqNHSLPygQFZKqshrxQrgsR4
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 07:55:20 -0000

On 10/24/2014 04:04 PM, Bodo Moeller wrote:
>
> >> Also note that in the *specific* hypothetical scenario that you 
> describe, the server actually would accept the fallback retry: you 
> said that TLS 1.0 is the highest protocol version supported by the 
> server; this is not higher than ClientHello.client_version in the TLS 
> 1.1 retry, so the server wouldn't reject.)
>
> > No, this is not what I was saying.
>
> Yes, it is ("Let's assume that the server supports all protocols 
> SSL3.0-TLS1.0").  I gather that's not what you meant, though.
>
( Sorry for confusion caused by two typos. )

Yes, I am talking about a "modern" server (so TLS1.2 is implemented or 
TLS1.3 in the near future).

> > In my scenario the server supports TLS1.2 in general with some 
> ciphersuites (and will support TLS1.3 in the future). The server is 
> configured in a way that the ciphersuite that it can negotiate with 
> the client requires SSLv3.
> >
> > What does draft-ietf-tls-downgrade-scsv-03 want the server to do 
> here: assume it's highest version is TLS1.2 or SSL 3.0? I.e. is the 
> max. version a static property on the server or dynamic based on 
> ciphers in ClientHello?
>


> There's no -03 draft, but the current draft's implication should be 
> clear: the server compares protocol versions only and hence rejects. 
> (Pretending that the highest protocol version is SSL 3.0 wouldn't make 
> sense.)
>

Thanks, that's what I thought the draft is saying. The server simply 
uses hardcoded value that represents the highest version it implements. 
Well, consider that if the server "pretends" that its version is SSL 3.0 
(because this is what it will negotiate in my example, along the lines 
of the logic for the client in the draft), this will avoid breaking the 
fallback connection, an unnecessary failure in the example I gave.

Repeating my point earlier, it looks kind of harsh to fail TLS 1.1 on 
the server when it can only negotiate SSL3.0 with that client.

In summary, I still don't see good justification for discrepancy: the 
client "SHOULD include the TLS_FALLBACK_SCSV", while the server "MUST 
respond with an inappropriate_fallback". I would prefer that the server 
had SHOULD keyword, which is a reasonable keyword for secure protocols. 
The draft is not MUST with TLS, of course, and it would be reasonable to 
give some wiggle room to server implementation to determine when to fail 
the handshake.


From nobody Sat Oct 25 01:02:46 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B91A86F4 for ; Sat, 25 Oct 2014 01:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE7r5FrxubkM for ; Sat, 25 Oct 2014 01:02:43 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27591A86E1 for ; Sat, 25 Oct 2014 01:02:41 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id gi9so3658900lab.21 for ; Sat, 25 Oct 2014 01:02:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tgTWJMUru0iKH5Lm3lB3k1BO7cACb5doH7GLimdfd1s=; b=Ue8yXN/76IqbIZzK6g9mVpcTK4qyqMv3n/sfEFXhvn7lq3aQtI0zWIM2GBvjAKWVAK OYPL15YQi4RT3wT7M6lULNToF+ajuybv8cSJuke7U48fQPZyBJC7M9uIe3nOP5UkVOMn UTp/loi2+zvc/Ocq6y+qZ9skYubjCCRyqfUJfcJN3t9r3Lp4wrYaWDXB2VGwSiJ11rlP cnEPcCT6+oHlOCzx7C3MDinceO4fUBJ/tsNhHv824yIRRRnj6YLKxv6PyAi11MualHwQ l4U43Qd9L+LK3zPFMkrSZ6c/SIXom3D6oD8Ga4GqFBGbFGA8ftu2ixk3RQgcE8WzsyRv VrEg==
MIME-Version: 1.0
X-Received: by 10.112.210.102 with SMTP id mt6mr9417805lbc.73.1414224160013; Sat, 25 Oct 2014 01:02:40 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Sat, 25 Oct 2014 01:02:39 -0700 (PDT)
In-Reply-To: <544B5764.9020006@brainhub.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5449E969.9000800@brainhub.org>  <544AB4B4.2010305@brainhub.org>  <544B5764.9020006@brainhub.org>
Date: Sat, 25 Oct 2014 01:02:39 -0700
Message-ID: 
From: Martin Thomson 
To: Andrey Jivsov 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-2oFsbRngVP2dYSFVS1RWCwZ1bk
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 08:02:44 -0000

On 25 October 2014 00:55, Andrey Jivsov  wrote:
> Repeating my point earlier, it looks kind of harsh to fail TLS 1.1 on the
> server when it can only negotiate SSL3.0 with that client.

Why, if the client is willing to do TLS 1.1, there's an unnecessary fallback.

Note that the maximum version in play is always the maximum version
that the server (or client) is willing to negotiate.  If a server is
capable of 1.2, but configured with 1.1, only downgraded handshakes to
1.0 or SSL will cause the alert to be generated.


From nobody Sat Oct 25 01:21:29 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4047A1A8029 for ; Sat, 25 Oct 2014 01:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X953IeL3PB0Z for ; Sat, 25 Oct 2014 01:21:24 -0700 (PDT)
Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375611A70E2 for ; Sat, 25 Oct 2014 01:21:24 -0700 (PDT)
Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-09v.sys.comcast.net with comcast id 7LMP1p0045Clt1L01LMPWs; Sat, 25 Oct 2014 08:21:23 +0000
Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-17v.sys.comcast.net with comcast id 7LMN1p00K4uhcbK01LMP8D; Sat, 25 Oct 2014 08:21:23 +0000
Message-ID: <544B5D82.2080900@brainhub.org>
Date: Sat, 25 Oct 2014 01:21:22 -0700
From: Andrey Jivsov 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Martin Thomson ,  Andrey Jivsov 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>	<5449E969.9000800@brainhub.org>		<544AB4B4.2010305@brainhub.org>		<544B5764.9020006@brainhub.org> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414225283; bh=WodbrnGB9+yp3aj3L2p4aZQvFh9b8oADGimPjKgT770=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qI/cEQbrqyGVCyg5YvFCeMZXxDCpL43ddW+bZoASQTznt77bk/WCCHrYaw+DLLinD 6op5yNn4zmkEQtF5CpJ1Pxp8M7mfY2Gc2KPDoTNu+5SOexw1fjouFT9SXvbEIdVTsn swnI0FpFPkQU/QCN22VcPgU+TpJ+XRSzDdcPccf8e+Exa0lvKPpVjtprVDhZpGYtpn Kv/cb13ndU80SmooQCgfbo2wOH38ZSyMauvb4JHICTEKpKdvrKaJZlI40EddozyvC+ Ya6fGUcuWLTywBqvcS01vOVK43yGS23b9UGAU+Zmf96LxSF7Q1/TpCFkw9o0vk4lVM i7fAwHIfc/OKg==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wiU9_-ezyAFmnHgwJtp1HLN34As
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 08:21:27 -0000

On 10/25/2014 01:02 AM, Martin Thomson wrote:
> On 25 October 2014 00:55, Andrey Jivsov  wrote:
>> Repeating my point earlier, it looks kind of harsh to fail TLS 1.1 on the
>> server when it can only negotiate SSL3.0 with that client.
> Why, if the client is willing to do TLS 1.1, there's an unnecessary fallback.
In my example the client failed TLS1.2 ClientHello and decided 
(incorrectly, due to network failure, etc) to do TLS1.1+TLS_FALLBACK_SCSV.

>
> Note that the maximum version in play is always the maximum version
> that the server (or client) is willing to negotiate.
The above is too general, so let's ignore it for now :-)
> If a server is
> capable of 1.2, but configured with 1.1, only downgraded handshakes to
> 1.0 or SSL will cause the alert to be generated.
I don't think this is what Bodo is saying. Sec 3 (server) is missing the 
concept of "configured", while the sec 4 (client) has it.

My example again is:

* the server capable of TLS 1.2 and lower. I mean, it will accept TLS 
1.2 ClientHello.
* the pair of the server and client happened to only able negotiate a 
ciphersuite that is set on the server to be SSL3.0
* client sends TLS1.1+TLS_FALLBACK_SCSV

So, what is server's maximum version? Bodo says it's TLS1.2. Thus, 
TLS1.1+TLS_FALLBACK_SCSV must fail. I say it's harsh because this pair 
can only negotiate SSL 3.0.


From SRS0=fQLM=7Q=acm.org=bmoeller@srs.kundenserver.de  Sat Oct 25 03:25:39 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEAD1A876F for ; Sat, 25 Oct 2014 03:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8ReSS_QS8sM for ; Sat, 25 Oct 2014 03:25:36 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1EB1A8768 for ; Sat, 25 Oct 2014 03:25:35 -0700 (PDT)
Received: from mail-yh0-f48.google.com (mail-yh0-f48.google.com [209.85.213.48]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0LroEc-1Y6kex1Rpm-013c3n; Sat, 25 Oct 2014 12:25:33 +0200
Received: by mail-yh0-f48.google.com with SMTP id v1so2272332yhn.7 for ; Sat, 25 Oct 2014 03:25:31 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.36.110 with SMTP id v74mr10358520yha.164.1414232731102;  Sat, 25 Oct 2014 03:25:31 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Sat, 25 Oct 2014 03:25:30 -0700 (PDT)
In-Reply-To: <544B5D82.2080900@brainhub.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5449E969.9000800@brainhub.org>  <544AB4B4.2010305@brainhub.org>  <544B5764.9020006@brainhub.org>  <544B5D82.2080900@brainhub.org>
Date: Sat, 25 Oct 2014 12:25:30 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0160c47891354405063cb782
X-Provags-ID: V02:K0:sxJU19nBQQK0FWaGr7rRGr50F72RPyh3hocTvcp4Ox/ C8ngTAg09sU+oqm5jIpotAfsIQhKB+M8AbrHMT70v30IIaXwbz 8RKrxrGdHgcjcoDNuEyrjxHEJT1KX+QjoXXadSgzmYwuKHHfCy wRLQyuR3a7zoUZuqUHFXoDZR7gyRf46RGIyjyC05uRQna6/zBz 4GcP8hd0eqMEhNUv9CTCB5LNlwL/pKLZs2pzeaAM6hAXB5ynnS Oqa8Htd/uQCjo+ObMF9p54ys2Iv9cfrn2nlwGyUKcCnulYHdGu yzxxIZdF0PLmizXaj9f+iM547YAcTrpMJP3bDCvAnrzuxAe1gr fX3l9SrJ9xlOKBAH0QO/CSSIt6IATdYHIaJxC3jnDKtCmFqyUT oQThJGrD5cuU7AU8z1/jybD52tAvNX3MFl70lwaTIQmu3v4BAG y90cS
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CIs1zLcwN0dxwsm7sHIuqXQQ6T4
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 10:26:08 -0000

--089e0160c47891354405063cb782
Content-Type: text/plain; charset=UTF-8

Andrey Jivsov :

 If a server is
>> capable of 1.2, but configured with 1.1, only downgraded handshakes to
>> 1.0 or SSL will cause the alert to be generated.
>>
>

>  I don't think this is what Bodo is saying. Sec 3 (server) is missing the
> concept of "configured", while the sec 4 (client) has it.
>

That's an inconsistency that I can fix. If a protocol version is completely
disabled in the server, of course using that version isn't supposed to be
an "inappropriate fallback".



> My example again is:
>
> * the server capable of TLS 1.2 and lower. I mean, it will accept TLS 1.2
> ClientHello.
>

And will negotiate TLS 1.2?

* the pair of the server and client happened to only able negotiate a
> ciphersuite that is set on the server to be SSL3.0
> * client sends TLS1.1+TLS_FALLBACK_SCSV
>
> So, what is server's maximum version? Bodo says it's TLS1.2. Thus,
> TLS1.1+TLS_FALLBACK_SCSV must fail. I say it's harsh because this pair can
> only negotiate SSL 3.0.
>

If the server is willing to negotiate TLS 1.2, then this is an
inappropriate fallback and will fail. It's not reasonable to optimize the
specification to provide extra error redundancy for blatantly stupid
servers as in this scenario (at the cost of making it more complex, which
can lead to other problems).

Bodo

--089e0160c47891354405063cb782
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Andr=
ey Jivsov <crypto@brainhub.org>:




If a server is

capable of 1.2, but configured with 1.1, only downgraded handshakes to

1.0 or SSL will cause the alert to be generated.
=C2=A0
=




I don't think this is what Bodo is saying. Sec 3 (server) is missing th=
e concept of "configured", while the sec 4 (client) has it.

That's an inconsistency that I can fix. =
If a protocol version is completely disabled in the server, of course using=
 that version isn't supposed to be an "inappropriate fallback"=
;.

=C2=A0

My example again is:



* the server capable of TLS 1.2 and lower. I mean, it will accept TLS 1.2 C=
lientHello.

And will negotiate TLS 1.2?=



* the pair of the server and client happened to only able negotiate a ciphe=
rsuite that is set on the server to be SSL3.0

* client sends TLS1.1+TLS_FALLBACK_SCSV



So, what is server's maximum version? Bodo says it's TLS1.2. Thus, =
TLS1.1+TLS_FALLBACK_SCSV must fail. I say it's harsh because this pair =
can only negotiate SSL 3.0.

If the serv=
er is willing to negotiate TLS 1.2, then this is an inappropriate fallback =
and will fail. It's not reasonable to optimize the specification to pro=
vide extra error redundancy for blatantly stupid servers as in this scenari=
o (at the cost of making it more complex, which can lead to other problems)=
.=C2=A0

Bodo


<=
/div>

--089e0160c47891354405063cb782--


From nobody Sat Oct 25 09:46:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4163E1A1A9B for ; Sat, 25 Oct 2014 09:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.328
X-Spam-Level: 
X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RAZOR2_CHECK=0.922] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NzSysGtR7Sj for ; Sat, 25 Oct 2014 09:46:32 -0700 (PDT)
Received: from vsp7.ballou.se (vsp7.ballou.se [91.189.40.103]) by ietfa.amsl.com (Postfix) with SMTP id 9FB7D1A1A02 for ; Sat, 25 Oct 2014 09:46:30 -0700 (PDT)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp7.ballou.se (Halon Mail Gateway) with ESMTP for ; Sat, 25 Oct 2014 18:46:26 +0200 (CEST)
Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id B212E1DE4C for ; Sat, 25 Oct 2014 18:46:26 +0200 (CEST)
Message-ID: <544BD3BF.9030702@streamsec.se>
Date: Sat, 25 Oct 2014 18:45:51 +0200
From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net>
In-Reply-To: <5438B82B.6090600@fifthhorseman.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/muHUc720zXoc_YiiJiLjKp5uQnA
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: henrick@streamsec.se
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 16:46:34 -0000

On 2014-10-11 06:55, Daniel Kahn Gillmor wrote:
> I'd appreciate any comments or suggestions, and particularly review
> related to the IANA considerations would be great.

It seems to me the the recommended Client Behavior and Server Behavior 
has to be simplified and strengthened, in order for the standard to meet 
the security objectives.

All relevant attacks here https://secure-resumption.com/ seem to involve 
a MITM server that chooses bad ServerDHParams for the server key 
exchange message.

   * Clearly, a MITM server might simply act as if it doesn't support 
the "elliptic_curves" extension. The server does not include a reply to 
the "elliptic_curves" extension in server_hello, so the client will not 
receive any indication of lack of support, until it receives 
server_key_exchange. At this point, the client might decide to terminate 
the handshake if the ServerDHParams aren't acceptable. Checking an 
arbitrary group by means of a binary compare, is only marginally harder 
than checking a named group.
   * Conversely, a MITM that connects to a legitimate server, will be 
perfectly able to carry out the secure resumption attacks, even if the 
MITM and the legitimate server negotiate using a fixed FFDHE group. (It 
is only the ServerDHParams used in the handshake between the legitimate 
client and the MITM that have to be doctored.)
   * Also, there doesn't seem to be any obvious harm in requiring that a 
compatible server always picks a ServerDHParams group with an estimated 
security equal to the minimum of the server certificate public key and 
the bulk encryption cipher, regardless of the presence or absence of an 
"elliptic_curves" extension in client_hello. If this group is encoded as 
an arbitrary group in ServerDHParams, there is no divergence from 
current standards at the protocol level.

Hence, in order to introduce as little complexity as possible into the 
client behavior and server behavior, as well as actually strengthening 
security by implementing this mechanism, I suggest something along these 
lines:

Client Behavior

Conforming clients MIGHT require that a FFDHE group with appropriate 
security bounds is presented by a specific server. If the use of such 
groups are required by the client, the client SHOULD NOT offer cipher 
suites that might force a compatible server to pick a group the client 
does not implement.

A client that requires the use of FFDHE groups MUST perform a binary 
compare of the ServerDHParams against the FFDHE group with the 
corresponding modulus size, and MUST end the handshake with an 
insufficient_security alert if the parameters do not match.

In order to avoid ambiguities if FFDHE groups are added, replaced or 
deprecated in future revisions of this standard, a compatible client 
SHOULD send an "elliptic_curves" extension in client_hello, to indicate 
support of specific groups.

Server Behavior

When a DHE cipher suite is negotiated, a compatible server SHOULD always 
pick a FFDHE group for ServerDHParams, with a security bound greater 
than the minimum of the server certificate public key and the bulk 
encryption cipher of the negotiated cipher suite. The server SHOULD NOT 
negotiate a DHE cipher suite, unless it implements at least one FFDHE 
group with at least the corresponding security bound.

If an "elliptic_curve" extension is included in client_hello, the server 
MUST NOT negotiate a DHE cipher suite that would require the server to 
pick a FFDHE group not included in the "elliptic_curve" extension sent 
by the client. NOTE: Since FFDHE groups might be replaced or added in 
future revisions of this standard, this check MUST be performed 
regardless if the "elliptic_curve" extension does not include any 
identifiers the server recognizes as FFDHE identifiers.



From nobody Sat Oct 25 10:09:06 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8101A1A87 for ; Sat, 25 Oct 2014 10:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Level: 
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3jEJbJSSUpf for ; Sat, 25 Oct 2014 10:09:02 -0700 (PDT)
Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5468B1A0019 for ; Sat, 25 Oct 2014 10:09:02 -0700 (PDT)
Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1Xi4pk-0007Mc-0i; Sat, 25 Oct 2014 19:08:56 +0200
Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1Xi4pj-0002uA-Q3; Sat, 25 Oct 2014 19:08:55 +0200
From: Florian Weimer 
To: Andrei Popov 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>        
Date: Sat, 25 Oct 2014 19:08:55 +0200
In-Reply-To:  (Andrei Popov's message of "Tue, 21 Oct 2014 00:09:00 +0000")
Message-ID: <87egtw84bc.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V9jHtunlJlcYhqXx11Y0n9srLXQ
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 17:09:04 -0000

* Andrei Popov:

> Yes, and you should be able to get away without Downgrade-SCSV if
> you do not do fallbacks (which are not even part of the TLS
> protocol).

But you still have to patch servers to protect broken clients from
their foolishness.  It doesn't matter that you don't do downgrades on
the server side.  That's one reason why I think TLS_FALLBACK_SCSV is
an embarrassment=E2=80=94it sanctifies the sinners, instead of forcing them=
 to
clean up their act.


From nobody Sat Oct 25 10:25:12 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32FF1A19F0 for ; Sat, 25 Oct 2014 10:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.679
X-Spam-Level: 
X-Spam-Status: No, score=-0.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep1KmFzUpp8U for ; Sat, 25 Oct 2014 10:25:08 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CD41A007F for ; Sat, 25 Oct 2014 10:25:07 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 8DA34817FA; Sat, 25 Oct 2014 20:25:05 +0300 (EEST)
Date: Sat, 25 Oct 2014 20:25:05 +0300
From: Ilari Liusvaara 
To: Henrick =?utf-8?Q?Hellstr=C3=B6m?= 
Message-ID: <20141025172504.GA2714@LK-Perkele-VII>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <544BD3BF.9030702@streamsec.se>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ShIj-QVNe2EdJETh6L1Wtn-N6II
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 17:25:10 -0000

On Sat, Oct 25, 2014 at 06:45:51PM +0200, Henrick Hellström wrote:
> On 2014-10-11 06:55, Daniel Kahn Gillmor wrote:
> >I'd appreciate any comments or suggestions, and particularly review
> >related to the IANA considerations would be great.
> 
> It seems to me the the recommended Client Behavior and Server Behavior has
> to be simplified and strengthened, in order for the standard to meet the
> security objectives.
> 
> All relevant attacks here https://secure-resumption.com/ seem to involve a
> MITM server that chooses bad ServerDHParams for the server key exchange
> message.

I see two problematic cases:
1) NG SKE gets presented as EC(!) SKE.
2) NG SKE gets presented to non-NG client.


1) The message is:

00 02 01 xx 00 01 00  

When interpretted as elliptic curve, this has curve type of 0, which is
not valid, so handshake can't work.


2) Here it might be a better idea to have group id in generator and have
modulus of 0, instead of generator 0 and modulus being group id.

This is to make buggy software more likely to blow up.

(after swapping the fields, the EC curve type is still 0).

16-bit prime does not make certain infamous TLS library reject the
handshake!



-Ilari


From nobody Sat Oct 25 11:06:47 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE501A1AFE for ; Sat, 25 Oct 2014 11:06:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level: 
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biV_uDhmyIoa for ; Sat, 25 Oct 2014 11:06:43 -0700 (PDT)
Received: from vsp8.ballou.se (vsp8.ballou.se [91.189.40.104]) by ietfa.amsl.com (Postfix) with SMTP id 1F61A1A1A79 for ; Sat, 25 Oct 2014 11:06:42 -0700 (PDT)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp8.ballou.se (Halon Mail Gateway) with ESMTP; Sat, 25 Oct 2014 20:06:37 +0200 (CEST)
Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id C953A1DE4C; Sat, 25 Oct 2014 20:06:37 +0200 (CEST)
Message-ID: <544BE68A.1010801@streamsec.se>
Date: Sat, 25 Oct 2014 20:06:02 +0200
From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ilari Liusvaara 
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <20141025172504.GA2714@LK-Perkele-VII>
In-Reply-To: <20141025172504.GA2714@LK-Perkele-VII>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hGruOP81PF7-hV3r6wYEJ2EvyPA
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: henrick@streamsec.se
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 18:06:46 -0000

On 2014-10-25 19:25, Ilari Liusvaara wrote:
> I see two problematic cases:
> 1) NG SKE gets presented as EC(!) SKE.
> 2) NG SKE gets presented to non-NG client.
>
>
> 1) The message is:
>
> 00 02 01 xx 00 01 00  
>
> When interpretted as elliptic curve, this has curve type of 0, which is
> not valid, so handshake can't work.

I think this should be of no consequence. A client that interprets a DHE 
SKE as an ECDHE SKE, despite having negotiated a DHE cipher suite, is 
broken beyond repair and would be pointless to try to be compatible with.


From nobody Sat Oct 25 11:14:41 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0621A1B13 for ; Sat, 25 Oct 2014 11:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rm7XOyAyneWj for ; Sat, 25 Oct 2014 11:14:36 -0700 (PDT)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F031A1B12 for ; Sat, 25 Oct 2014 11:14:35 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 8F77869964; Sat, 25 Oct 2014 21:14:33 +0300 (EEST)
Date: Sat, 25 Oct 2014 21:14:33 +0300
From: Ilari Liusvaara 
To: Henrick =?utf-8?Q?Hellstr=C3=B6m?= 
Message-ID: <20141025181433.GA5567@LK-Perkele-VII>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <20141025172504.GA2714@LK-Perkele-VII> <544BE68A.1010801@streamsec.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <544BE68A.1010801@streamsec.se>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/O5kiC3qLTIg1nTKnCIshbNpyKcA
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 18:14:37 -0000

On Sat, Oct 25, 2014 at 08:06:02PM +0200, Henrick Hellström wrote:
> On 2014-10-25 19:25, Ilari Liusvaara wrote:
> >I see two problematic cases:
> >1) NG SKE gets presented as EC(!) SKE.
> >2) NG SKE gets presented to non-NG client.
> >
> >
> >1) The message is:
> >
> >00 02 01 xx 00 01 00  
> >
> >When interpretted as elliptic curve, this has curve type of 0, which is
> >not valid, so handshake can't work.
> 
> I think this should be of no consequence. A client that interprets a DHE SKE
> as an ECDHE SKE, despite having negotiated a DHE cipher suite, is broken
> beyond repair and would be pointless to try to be compatible with.

Unfortunately, attacker can make client interpret DHE SKE as ECDHE SKE
(or vice versa). TLS key exchange is just screwed up.

Oh, I also missed interpretting ECDHE SKE as posibly-NG DHE. This always
results in prime of length 256 or above. So if prime length is restricted for
NG DHE, these can't be confused with NG DHE.


-Ilari


From nobody Sat Oct 25 12:41:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD3E1A3BA7 for ; Sat, 25 Oct 2014 12:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XHdzDN_8D7s for ; Sat, 25 Oct 2014 12:41:35 -0700 (PDT)
Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117411A6EDC for ; Sat, 25 Oct 2014 12:41:34 -0700 (PDT)
Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-08v.sys.comcast.net with comcast id 7XgJ1p00A4ueUHc01Xharh; Sat, 25 Oct 2014 19:41:34 +0000
Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-03v.sys.comcast.net with comcast id 7XhZ1p0064uhcbK01XhZ6H; Sat, 25 Oct 2014 19:41:34 +0000
Message-ID: <544BFCED.9080904@brainhub.org>
Date: Sat, 25 Oct 2014 12:41:33 -0700
From: Andrey Jivsov 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5449E969.9000800@brainhub.org>  <544AB4B4.2010305@brainhub.org>  <544B5764.9020006@brainhub.org>  <544B5D82.2080900@brainhub.org> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414266094; bh=b/0Hkeb/R1TKZFSDguw/p4wYy93pI5wqVl1hgTI/Tfw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=klJUDi4y4JLA0gVA/Q+wueMmJqnW1ue4TD1lELnHAkExfoFH5S4AZOZV2JO6LHbZk h9Mxwbo0kfHNwklJizcJxW9Rd/Frb7X6ZKEs3fKvwBX+mm9hfOv4gpq11W0OmbUbPu +DsquSADIwfa64uFfF9jVXkc7/dwvJWeHi0F80FYdo946dA0ZHEHfVZMgqQo7bVJrC nwkSv+ZYhUuOCiwczcZdAvy/rmRqmBl2KdVgnB+Y+TtInWmsYG5rbzazBqZ5btbTNG Vf9PRWXX1MZHU9q5QS3tKxpcdKNnLGNW+yknx/8uAoffp0k2nqbJkteS+M3GGGO3G2 dL0c74qAcG+fw==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CCTzyhxJe1XbR-0G7GZFU-iPseE
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 19:41:37 -0000

On 10/25/2014 03:25 AM, Bodo Moeller wrote:
> Andrey Jivsov >:
>
>         If a server is
>         capable of 1.2, but configured with 1.1, only downgraded
>         handshakes to
>         1.0 or SSL will cause the alert to be generated.
>
>     I don't think this is what Bodo is saying. Sec 3 (server) is missing
>     the concept of "configured", while the sec 4 (client) has it.
>
>
> That's an inconsistency that I can fix. If a protocol version is
> completely disabled in the server, of course using that version isn't
> supposed to be an "inappropriate fallback".
>
>     My example again is:
>
>     * the server capable of TLS 1.2 and lower. I mean, it will accept
>     TLS 1.2 ClientHello.
>
>
> And will negotiate TLS 1.2?
>
>     * the pair of the server and client happened to only able negotiate
>     a ciphersuite that is set on the server to be SSL3.0
>     * client sends TLS1.1+TLS_FALLBACK_SCSV
>
>     So, what is server's maximum version? Bodo says it's TLS1.2. Thus,
>     TLS1.1+TLS_FALLBACK_SCSV must fail. I say it's harsh because this
>     pair can only negotiate SSL 3.0.
>
>
> If the server is willing to negotiate TLS 1.2, then this is an
> inappropriate fallback and will fail. It's not reasonable to optimize
> the specification to provide extra error redundancy for blatantly stupid
> servers as in this scenario (at the cost of making it more complex,
> which can lead to other problems).
>

Regarding "blatantly stupid servers",

what you are saying is that the set of ciphers that can be negotiated 
with TLS1.2 must be a superset of the ciphers that can be negotiated 
with TLS1.1 in any server configuration, and so on to SSL 3.0

I am not sure that this will always be possible. Let's say I must offer 
RC4-MD5 for legacy products that only support SSL 3.0.

I think it would be more secure to offer

   TLS1.2: X, Y
   TLS1.1: X
   TLS1.0: X
   SSL3.0: X, RC4-MD5

than

   TLS1.2: X, Y, RC4-MD5
   TLS1.1: X, RC4-MD5
   TLS1.0: X, RC4-MD5
   SSL3.0: X, RC4-MD5

where X, Y are reasonable sets that currently works well with modern 
products.

The last line in each of the two sets above is a weak configuration, but 
this is the only cipher+protocol that outdated and unpatched clients can 
negotiate.

If I make RC4-MD5 available for higher protocols, this will mean that 
it's now potentially available to modern clients. Hopefully the clients 
don't negotiate it, or at the very least order it at the bottom of the 
ClientHello, however, there is now an insecure RC4-MD5 offered with 
TLS1.2. At the very least it looks bad to auditors, scanners, etc.

My example earlier in this thread involved the modern client negotiating 
RC4-MD5, supposedly due to misconfiguration. I think the first 
configuration on the server is slightly better because SSL 3.0 would 
likely be disabled by some global override on the client, preventing 
this scenario.

I think one should accept a small probability for TLS1.2-capable servers 
to negotiate lower version with TLS1.2 clients.


From nobody Sat Oct 25 12:52:01 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6CA1A6F0D for ; Sat, 25 Oct 2014 12:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.989
X-Spam-Level: 
X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpDZxD5G9SEF for ; Sat, 25 Oct 2014 12:51:55 -0700 (PDT)
Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D5A1A1AB8 for ; Sat, 25 Oct 2014 12:51:55 -0700 (PDT)
Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s9PJprT8002025; Sat, 25 Oct 2014 15:51:54 -0400
Date: Sat, 25 Oct 2014 15:51:53 -0400 (EDT)
From: Nikos Mavrogiannopoulos 
To: henrick@streamsec.se
Message-ID: <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com>
In-Reply-To: <544BD3BF.9030702@streamsec.se>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.5.82.6]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF29 (Linux)/8.0.6_GA_5922)
Thread-Topic: I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
Thread-Index: QXktS8+7r5wYADvNb06ORXu3YFFUgw==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UdP1AHuhLhUfhY_dOl1JCNixTfg
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 19:51:59 -0000

> It seems to me the the recommended Client Behavior and Server Behavior
> has to be simplified and strengthened, in order for the standard to meet
> the security objectives.

Could you elaborate on which security objectives are you referring to?

> All relevant attacks here https://secure-resumption.com/ seem to involve
> a MITM server that chooses bad ServerDHParams for the server key
> exchange message.
>    * Clearly, a MITM server might simply act as if it doesn't support
> the "elliptic_curves" extension. The server does not include a reply to
> the "elliptic_curves" extension in server_hello, so the client will not
> receive any indication of lack of support, until it receives
> server_key_exchange. At this point, the client might decide to terminate
> the handshake if the ServerDHParams aren't acceptable. Checking an
> arbitrary group by means of a binary compare, is only marginally harder
> than checking a named group.
[...]
> A client that requires the use of FFDHE groups MUST perform a binary
> compare of the ServerDHParams against the FFDHE group with the
> corresponding modulus size, and MUST end the handshake with an
> insufficient_security alert if the parameters do not match.

What is the advantage of that proposal? It is more complex, and a security
protocol should strive for simplicity. I see three disadvantages:
1. More bytes to send in a handshake, especially since we are talking about
large groups (that also results to more memory used by implementations
that have to cache those messages until the handshake is finished).
2. Instead of simple maps to known parameters, checks are needed adding more 
space for errors.
3. There are known attacks against the current ServerKeyExchange format which
remain applicable if we go this path (a sufficiently long DH serverkeyexchange
message can be parsed as an ECDH serverkeyexchage).


Furthermore, I'd like to propose to further simplify the message for ServerDHParams
used by the draft, and convert it to a deliberately incompatible format with the 
ServerDHParams as well ServerECDHParams. That way it can be ensured ensure that there
cannot be any mitm taking advantage of the similarities.

regards,
Nikos


From nobody Sat Oct 25 12:56:01 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D0A1A6EDC for ; Sat, 25 Oct 2014 12:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.078
X-Spam-Level: 
X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RAZOR2_CHECK=0.922, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcgcI-5DnRww for ; Sat, 25 Oct 2014 12:55:59 -0700 (PDT)
Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220D61A1AB8 for ; Sat, 25 Oct 2014 12:55:59 -0700 (PDT)
Received: by mail-yh0-f52.google.com with SMTP id f10so2800730yha.25 for ; Sat, 25 Oct 2014 12:55:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5mRUb+Bmw59HjrW/bEY+bwfw0JlXK5gxYpSqZdd4vR8=; b=Nn3UEjYJz16LsMUf+FFnNJefas18T4ArLzWmw16tCz68ILMJcJf+W1gEItcCzsW9IN oNCI845w9s3f2dPdWPY73wPVc1UvPj8D6QyTJMOBPrTRfD/eYKHyqO+mEeXI0w7uPLbk oXZPE4QqSWi0FbzLtd2gcjLvkR4lWCqWqPYA3hw62IjbFNCzvMoArUdM9yv20vRQrBOk f/7tSwbofV3Uf0jFSWIP7q5V1Qgnb1YHn62T04TwB74a065UcBLFBwh5fE7Mpr3nbfOi jUHnlwPgUFtBt4S5dnZ+1O2M+O3aspFE2+QS6jWNQReUJVZiaC7eG5csqzw1Y8e4pMsM 1pwQ==
MIME-Version: 1.0
X-Received: by 10.170.87.7 with SMTP id e7mr15717293yka.126.1414266958422; Sat, 25 Oct 2014 12:55:58 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Sat, 25 Oct 2014 12:55:58 -0700 (PDT)
In-Reply-To: <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com>
Date: Sat, 25 Oct 2014 12:55:58 -0700
Message-ID: 
From: Watson Ladd 
To: Nikos Mavrogiannopoulos 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KRk5HMKoEx_Lfx1ZQZ12Fn7h1tQ
Cc: "tls@ietf.org" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 19:56:00 -0000

On Sat, Oct 25, 2014 at 12:51 PM, Nikos Mavrogiannopoulos
 wrote:
>> It seems to me the the recommended Client Behavior and Server Behavior
>> has to be simplified and strengthened, in order for the standard to meet
>> the security objectives.
>
> Could you elaborate on which security objectives are you referring to?
>
>> All relevant attacks here https://secure-resumption.com/ seem to involve
>> a MITM server that chooses bad ServerDHParams for the server key
>> exchange message.
>>    * Clearly, a MITM server might simply act as if it doesn't support
>> the "elliptic_curves" extension. The server does not include a reply to
>> the "elliptic_curves" extension in server_hello, so the client will not
>> receive any indication of lack of support, until it receives
>> server_key_exchange. At this point, the client might decide to terminate
>> the handshake if the ServerDHParams aren't acceptable. Checking an
>> arbitrary group by means of a binary compare, is only marginally harder
>> than checking a named group.
> [...]
>> A client that requires the use of FFDHE groups MUST perform a binary
>> compare of the ServerDHParams against the FFDHE group with the
>> corresponding modulus size, and MUST end the handshake with an
>> insufficient_security alert if the parameters do not match.
>
> What is the advantage of that proposal? It is more complex, and a security
> protocol should strive for simplicity. I see three disadvantages:
> 1. More bytes to send in a handshake, especially since we are talking about
> large groups (that also results to more memory used by implementations
> that have to cache those messages until the handshake is finished).
> 2. Instead of simple maps to known parameters, checks are needed adding more
> space for errors.
> 3. There are known attacks against the current ServerKeyExchange format which
> remain applicable if we go this path (a sufficiently long DH serverkeyexchange
> message can be parsed as an ECDH serverkeyexchage).

And 4: session_hash solves the same problem if I understand the
elements of it correctly, and we need it anyway because of this
ambiguity in parsing mentioned above. So do we even need this draft?

>
>
> Furthermore, I'd like to propose to further simplify the message for ServerDHParams
> used by the draft, and convert it to a deliberately incompatible format with the
> ServerDHParams as well ServerECDHParams. That way it can be ensured ensure that there
> cannot be any mitm taking advantage of the similarities.
>
> regards,
> Nikos
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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


From nobody Sat Oct 25 13:16:50 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0421A6F6B for ; Sat, 25 Oct 2014 13:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHmfYjd3wI_F for ; Sat, 25 Oct 2014 13:16:46 -0700 (PDT)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617C81A6F3D for ; Sat, 25 Oct 2014 13:16:45 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 9285B1887A1; Sat, 25 Oct 2014 23:16:42 +0300 (EEST)
Date: Sat, 25 Oct 2014 23:16:42 +0300
From: Ilari Liusvaara 
To: Watson Ladd 
Message-ID: <20141025201642.GA7408@LK-Perkele-VII>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XPbP-TYu95M8BFeJRhIrP1r5MyE
Cc: "tls@ietf.org" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 20:16:48 -0000

On Sat, Oct 25, 2014 at 12:55:58PM -0700, Watson Ladd wrote:
> On Sat, Oct 25, 2014 at 12:51 PM, Nikos Mavrogiannopoulos
>  wrote:
>
> > 3. There are known attacks against the current ServerKeyExchange format which
> > remain applicable if we go this path (a sufficiently long DH serverkeyexchange
> > message can be parsed as an ECDH serverkeyexchage).
> 
> And 4: session_hash solves the same problem if I understand the
> elements of it correctly, and we need it anyway because of this
> ambiguity in parsing mentioned above. So do we even need this draft?

AFAIK, no, it won't, at least not completely.

(TLS 1.3 has this problem fixed, even without session_hash[1]).


[1] Without session_hash TLS 1.3 is broken in other ways without DH
order check (and one can't rely on endpoints to perform such check
even if it is feasible, so session_hash is a good idea there too).


-Ilari


From nobody Sat Oct 25 13:52:16 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD13C1A6EEC for ; Sat, 25 Oct 2014 13:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmYScDNvGHcs for ; Sat, 25 Oct 2014 13:52:13 -0700 (PDT)
Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DF01A1BF9 for ; Sat, 25 Oct 2014 13:52:13 -0700 (PDT)
Received: by mail-ob0-f173.google.com with SMTP id wp4so1795668obc.4 for ; Sat, 25 Oct 2014 13:52:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gQZG4iiVafdRsdkIpGvc+/+jNn6gGibOO4MI2VWII5M=; b=d091nTGSNFg3ScT6rIvoqf0P7C5qlGdScsV4GF08tM+1Ow3+pRMYt8+rf3/Don3Krv BnbySjnfm36n4Av4DW2tuzs/opT/S+jvHu8CsT97hCHnsqPCWF6d8Ch4YgVDp91TGUQX cDpbmeXUe/RTVB8AqLxLmhopILfgp+gZu2PCSGiYJuPSe8ZopinGUrfy+966s8dWpIIf NzahsjJfEspuC3KKCCcXmuMm7CUel1T5/4LVwTn7HnR1SDwHqXdy9C2XSMPcf75xgeFK L8OxsUdIcz0zyTvuiDTyx7uS36BdQjCCl6t8I8CPbFOjDfHdy6KVONlpaGsjNBDCBFHa 1lJg==
X-Gm-Message-State: ALoCoQlfbOmxY07tj8UneB6ts8qirgfHwxc6ZURoppQJ9mZ0mDqGnT+u5Rmt8KwAKF/c9c/r3hsD
MIME-Version: 1.0
X-Received: by 10.202.205.147 with SMTP id d141mr3206389oig.67.1414270332804;  Sat, 25 Oct 2014 13:52:12 -0700 (PDT)
Received: by 10.76.105.113 with HTTP; Sat, 25 Oct 2014 13:52:12 -0700 (PDT)
In-Reply-To: <544BFCED.9080904@brainhub.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5449E969.9000800@brainhub.org>  <544AB4B4.2010305@brainhub.org>  <544B5764.9020006@brainhub.org>  <544B5D82.2080900@brainhub.org>  <544BFCED.9080904@brainhub.org>
Date: Sat, 25 Oct 2014 13:52:12 -0700
Message-ID: 
From: Brian Smith 
To: Andrey Jivsov 
Content-Type: multipart/alternative; boundary=001a11352f46cdb7230506457806
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8KZ31RLiRPOWQZ_W2kx3GYsp81g
Cc: "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 20:52:14 -0000

--001a11352f46cdb7230506457806
Content-Type: text/plain; charset=UTF-8

On Sat, Oct 25, 2014 at 12:41 PM, Andrey Jivsov  wrote:
>
> what you are saying is that the set of ciphers that can be negotiated with
> TLS1.2 must be a superset of the ciphers that can be negotiated with TLS1.1
> in any server configuration, and so on to SSL 3.0
>

No. The set of ciphers that can be negotiated with TLS 1.2 must overlap
with the set of ciphers that clients offer in their TLS 1.2 handshake.


> I am not sure that this will always be possible. Let's say I must offer
> RC4-MD5 for legacy products that only support SSL 3.0.
>
> I think it would be more secure to offer
>
>   TLS1.2: X, Y
>   TLS1.1: X
>   TLS1.0: X
>   SSL3.0: X, RC4-MD5


That seems OK to me. You just need to make sure that X is offered by all
the clients you want to support that support TLS_FALLBACK_SCSV and that
don't support TLS 1.2, and that at least one of {X, Y}  is supported by by
all TLS-1.2-capable clients that support TLS_FALLBACK_SCSV. (Approximately.)

Cheers,
Brian

--001a11352f46cdb7230506457806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On S=
at, Oct 25, 2014 at 12:41 PM, Andrey Jivsov <crypto@brainhub.org&g=
t; wrote:

what you are saying is that the set of ciphers that can be negotiated with =
TLS1.2 must be a superset of the ciphers that can be negotiated with TLS1.1=
 in any server configuration, and so on to SSL 3.0
No. The set of ciphers that can be negotiated with TLS 1.2 must=
 overlap with the set of ciphers that clients offer in their TLS 1.2 handsh=
ake.
=C2=A0
I am not sure that this will al=
ways be possible. Let's say I must offer RC4-MD5 for legacy products th=
at only support SSL 3.0.



I think it would be more secure to offer



=C2=A0 TLS1.2: X, Y

=C2=A0 TLS1.1: X

=C2=A0 TLS1.0: X

=C2=A0 SSL3.0: X, RC4-MD5

That seems OK to =
me. You just need to make sure that X is offered by all the clients you wan=
t to support that support TLS_FALLBACK_SCSV and that don't support TLS =
1.2, and that at least one of {X, Y} =C2=A0is supported by by all TLS-1.2-c=
apable clients that support TLS_FALLBACK_SCSV. (Approximately.)
<=
br>
Cheers,
Brian



--001a11352f46cdb7230506457806--


From nobody Sat Oct 25 14:36:13 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538C61A1AF8 for ; Sat, 25 Oct 2014 14:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0kiD-FFqZ-I for ; Sat, 25 Oct 2014 14:36:10 -0700 (PDT)
Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCA841A1AD5 for ; Sat, 25 Oct 2014 14:36:09 -0700 (PDT)
Received: by mail-yh0-f54.google.com with SMTP id 29so3130180yhl.27 for ; Sat, 25 Oct 2014 14:36:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0kxQLM99q3Ac4kcrShLVMIsxaieDyQnzaxpLviKabQY=; b=SGpBZKpcauwC5HeGv4ojQrEmaWGE2QExf9yan32L3vSjjYKLqAUZ5t43/VaQUOFYSh xrbc6j18eigctawN1F6QX+A+Qi9AGxRoRctcKOJar/9tcu6O/f8dncM+YfVq2EaKajTR AJRIKVvzHh1BF0DIIsA4nm8+pmtkPH/fPvIesKTnjFo5++WPPkFZgxbeWr8XWsRcENt1 bo1HLXNjx1dXVgO1ITdoh/w/oOB2+oK6sGOmHTAQri3BYeCtt1pbKtiwnxFbRnZgu6aM chBIKJowhsKgKx+Ul+Ww0Fe1V+zi574h/FC2622C7at8UhaNaprNLlqszU4uSQ9mdhOr 4IdQ==
MIME-Version: 1.0
X-Received: by 10.236.46.38 with SMTP id q26mr4291734yhb.176.1414272969198; Sat, 25 Oct 2014 14:36:09 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Sat, 25 Oct 2014 14:36:09 -0700 (PDT)
In-Reply-To: <20141025201642.GA7408@LK-Perkele-VII>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com>  <20141025201642.GA7408@LK-Perkele-VII>
Date: Sat, 25 Oct 2014 14:36:09 -0700
Message-ID: 
From: Watson Ladd 
To: Ilari Liusvaara 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/a6KyQaMikQ9idGTEE0lMBV2gXuA
Cc: "tls@ietf.org" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 21:36:11 -0000

On Sat, Oct 25, 2014 at 1:16 PM, Ilari Liusvaara
 wrote:
> On Sat, Oct 25, 2014 at 12:55:58PM -0700, Watson Ladd wrote:
>> On Sat, Oct 25, 2014 at 12:51 PM, Nikos Mavrogiannopoulos
>>  wrote:
>>
>> > 3. There are known attacks against the current ServerKeyExchange format which
>> > remain applicable if we go this path (a sufficiently long DH serverkeyexchange
>> > message can be parsed as an ECDH serverkeyexchage).
>>
>> And 4: session_hash solves the same problem if I understand the
>> elements of it correctly, and we need it anyway because of this
>> ambiguity in parsing mentioned above. So do we even need this draft?
>
> AFAIK, no, it won't, at least not completely.

I'm afraid I didn't realize how what I wrote would be read. It seems
to me that the session_hash doesn't necessarily fix the ambiguity
issue, but does ensure that sending bad groups will achieve nothing
for an attacker. Even if we adopt this draft for DHE, session_hash is
still needed in TLS 1.2. So what does this draft get us, assuming
session_hash is deployed?

>
> (TLS 1.3 has this problem fixed, even without session_hash[1]).
>
>
> [1] Without session_hash TLS 1.3 is broken in other ways without DH
> order check (and one can't rely on endpoints to perform such check
> even if it is feasible, so session_hash is a good idea there too).
>
>
> -Ilari



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


From nobody Sat Oct 25 14:53:52 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BD61A0264 for ; Sat, 25 Oct 2014 14:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level: 
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAgGIm0vsIGV for ; Sat, 25 Oct 2014 14:53:49 -0700 (PDT)
Received: from vsp2.ballou.se (vsp2.ballou.se [91.189.40.83]) by ietfa.amsl.com (Postfix) with SMTP id 99DC01A0231 for ; Sat, 25 Oct 2014 14:53:47 -0700 (PDT)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp2.ballou.se (Halon Mail Gateway) with ESMTP; Sat, 25 Oct 2014 23:53:42 +0200 (CEST)
Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id EA83D1DE4C; Sat, 25 Oct 2014 23:53:41 +0200 (CEST)
Message-ID: <544C1BC3.5060204@streamsec.se>
Date: Sat, 25 Oct 2014 23:53:07 +0200
From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com>
In-Reply-To: <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mHxLlT_Gvcg-oOVNbx0nVGqJxRg
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: henrick@streamsec.se
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 21:53:51 -0000

On 2014-10-25 21:51, Nikos Mavrogiannopoulos wrote:
>> It seems to me the the recommended Client Behavior and Server Behavior
>> has to be simplified and strengthened, in order for the standard to meet
>> the security objectives.
>
> Could you elaborate on which security objectives are you referring to?

Second paragraph of section 6.3 Arbitrary groups:

>    Note that in several known attacks against TLS and SSL
>    [SECURE-RESUMPTION] [CROSS-PROTOCOL] [SSL3-ANALYSIS], a malicious
>    server uses a deliberately broken FFDHE group to impersonate the
>    client to a different server."


> What is the advantage of that proposal? It is more complex, and a security
> protocol should strive for simplicity.

In my view, the current draft leads to a lot more complex 
implementations, compared to my proposal.

You get complexity for two major reasons:
   * When adding new abilities in a manner that is not backwards 
compatible by design.
   * When balancing security requirements against interoperability 
requirements, without clear indications in the standards how these 
requirements should be balanced.

The problem a client faces, is that if it supports TLS 1.0 through TLS 
1.2, it will have to be prepared to deal with servers sending arbitrary 
FF DHE groups anyway. While I agree the ambiguity of the 
server_key_exchange message is a concern, implementing the draft-02 
doesn't resolve that ambiguity. Implementing TLS 1.3 and dropping 
support for older versions might be solution, but that is not going to 
happen any time soon.

Consequently, I would argue that a recommendation that ECDHE should only 
use named curves, and FF DHE only use standard groups encoded as 
arbitrary groups, would be closer to reality, lead to greater security 
at the expense of less interoperability issues, and make both server 
implementations and client implementations (that require backwards 
compatibility with older peers) *less* complex.


From nobody Sat Oct 25 15:05:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414641A6EE4 for ; Sat, 25 Oct 2014 15:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWrt3-YWu5U6 for ; Sat, 25 Oct 2014 15:05:18 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232421A1B2B for ; Sat, 25 Oct 2014 15:05:17 -0700 (PDT)
Received: from BY2PR03MB427.namprd03.prod.outlook.com (10.141.141.146) by BY2PR03MB427.namprd03.prod.outlook.com (10.141.141.146) with Microsoft SMTP Server (TLS) id 15.1.6.9; Sat, 25 Oct 2014 22:05:15 +0000
Received: from BY2PR03MB427.namprd03.prod.outlook.com ([10.141.141.146]) by BY2PR03MB427.namprd03.prod.outlook.com ([10.141.141.146]) with mapi id 15.01.0006.000; Sat, 25 Oct 2014 22:05:15 +0000
From: Andrei Popov 
To: Florian Weimer 
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb
Thread-Index: AQHP8HZg9sDRYWQ6PES8iSXaCbS05JxBXHgQ
Date: Sat, 25 Oct 2014 22:05:14 +0000
Message-ID: 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>         <87egtw84bc.fsf@mid.deneb.enyo.de>
In-Reply-To: <87egtw84bc.fsf@mid.deneb.enyo.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [50.46.236.51]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB427;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0375972289
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377454003)(13464003)(74316001)(50986999)(54356999)(85306004)(106116001)(106356001)(19580395003)(19580405001)(93886004)(108616004)(76576001)(31966008)(122556002)(101416001)(40100003)(64706001)(76176999)(20776003)(86612001)(86362001)(76482002)(92566001)(99396003)(21056001)(120916001)(66066001)(4396001)(85852003)(2656002)(33646002)(87936001)(99286002)(107046002)(110136001)(95666004)(105586002)(97736003)(80022003)(46102003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB427; H:BY2PR03MB427.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SotvKDPRgXdktdFatgSXSptEawc
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 22:05:22 -0000

WWVzLCB0aGVyZSBpcyBzb21lIHRydXRoIGluIHdoYXQgeW91IHNheS4gRG93bmdyYWRlLVNDU1Yg
aXMgYSBoYWNrLCBidXQgaXQgd2lsbCBiZSBoYXJkL2ltcG9zc2libGUgdG8gY29udmluY2UgYnJv
d3NlciB2ZW5kb3JzIHRvIHN0b3AgZG9pbmcgZmFsbGJhY2tzLiBQZXJoYXBzIHRoYXQncyBiZWNh
dXNlIGJyb3dzZXJzIGNvbXBldGUgb24gaW50ZXJvcGVyYWJpbGl0eSBhbmQgY29ubmVjdGl2aXR5
LCBub3Qgc2VjdXJpdHk/DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBGbG9y
aWFuIFdlaW1lciBbbWFpbHRvOmZ3QGRlbmViLmVueW8uZGVdIA0KU2VudDogU2F0dXJkYXksIE9j
dG9iZXIgMjUsIDIwMTQgMTA6MDkgQU0NClRvOiBBbmRyZWkgUG9wb3YNCkNjOiBCb2RvIE1vZWxs
ZXI7IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIFRoZSBUTFNfRkFMTEJBQ0tfU0NT
ViB0aW1lIGJvbWINCg0KKiBBbmRyZWkgUG9wb3Y6DQoNCj4gWWVzLCBhbmQgeW91IHNob3VsZCBi
ZSBhYmxlIHRvIGdldCBhd2F5IHdpdGhvdXQgRG93bmdyYWRlLVNDU1YgaWYgeW91IA0KPiBkbyBu
b3QgZG8gZmFsbGJhY2tzICh3aGljaCBhcmUgbm90IGV2ZW4gcGFydCBvZiB0aGUgVExTIHByb3Rv
Y29sKS4NCg0KQnV0IHlvdSBzdGlsbCBoYXZlIHRvIHBhdGNoIHNlcnZlcnMgdG8gcHJvdGVjdCBi
cm9rZW4gY2xpZW50cyBmcm9tIHRoZWlyIGZvb2xpc2huZXNzLiAgSXQgZG9lc24ndCBtYXR0ZXIg
dGhhdCB5b3UgZG9uJ3QgZG8gZG93bmdyYWRlcyBvbiB0aGUgc2VydmVyIHNpZGUuICBUaGF0J3Mg
b25lIHJlYXNvbiB3aHkgSSB0aGluayBUTFNfRkFMTEJBQ0tfU0NTViBpcyBhbiBlbWJhcnJhc3Nt
ZW504oCUaXQgc2FuY3RpZmllcyB0aGUgc2lubmVycywgaW5zdGVhZCBvZiBmb3JjaW5nIHRoZW0g
dG8gY2xlYW4gdXAgdGhlaXIgYWN0Lg0K


From nobody Sat Oct 25 20:35:40 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230601A3B9D for ; Sat, 25 Oct 2014 20:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKv6LFid6ZVz for ; Sat, 25 Oct 2014 20:35:33 -0700 (PDT)
Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B86A1A1F20 for ; Sat, 25 Oct 2014 20:35:33 -0700 (PDT)
Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-04v.sys.comcast.net with comcast id 7fbK1p00457bBgG01fbY11; Sun, 26 Oct 2014 03:35:32 +0000
Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-13v.sys.comcast.net with comcast id 7fbV1p0034uhcbK01fbVeV; Sun, 26 Oct 2014 03:35:32 +0000
Message-ID: <544C6C00.3070903@brainhub.org>
Date: Sat, 25 Oct 2014 20:35:28 -0700
From: Andrey Jivsov 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Brian Smith 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5449E969.9000800@brainhub.org>  <544AB4B4.2010305@brainhub.org>  <544B5764.9020006@brainhub.org>  <544B5D82.2080900@brainhub.org>  <544BFCED.9080904@brainhub.org> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414294532; bh=NPMoKAR87VFtScrflnU+BVXPcdKuGgSOtduFwXYDfWQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DBJFi27dPocSf0NedobVXJNKAjpRhYDBkCjIaXONItUK8UT7A9OtRaQLvgXBuKSo9 0B4tU/6QuVZ4poh6cW9/X3Y3jd3gG7rxYpE5KSbXJRX6K4NB/8qVwvGhWLDFlNttHh zk9yE/OL6e4MZQFp+CM7fncblkGDq9z7XYsyvE+zWPQbHI6v2n7rtEZy7KdkyL30w2 38OKpJW6hpIRtTdSMao4YW3ULREeMDtDYS9lXoutlWb8jInbzKz7vLMeUvr9hrYuCj IiIP2ajpXQpjAxGP3fpIoToNFzlfB4fEhzU3N0tcT6Hx+zsvtWN8wK0kwT+SfXY08L Vk+IBnQcuyI0w==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KnbCieOv1_lGo-OszcDpYCUMUA0
Cc: "" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Oct 2014 03:35:38 -0000

On 10/25/2014 01:52 PM, Brian Smith wrote:
> On Sat, Oct 25, 2014 at 12:41 PM, Andrey Jivsov  > wrote:
>
>     what you are saying is that the set of ciphers that can be
>     negotiated with TLS1.2 must be a superset of the ciphers that can be
>     negotiated with TLS1.1 in any server configuration, and so on to SSL 3.0
>
>
> No. The set of ciphers that can be negotiated with TLS 1.2 must overlap
> with the set of ciphers that clients offer in their TLS 1.2 handshake.

I was talking about the way ciphers are structured on the server, but I 
think we agree because you accept the below "table" and use the word 
"overlap" (as oppose to superset).

>
>     I am not sure that this will always be possible. Let's say I must
>     offer RC4-MD5 for legacy products that only support SSL 3.0.
>
>     I think it would be more secure to offer
>
>        TLS1.2: X, Y
>        TLS1.1: X
>        TLS1.0: X
>        SSL3.0: X, RC4-MD5
>
>
> That seems OK to me. You just need to make sure that X is offered by all
> the clients you want to support that support TLS_FALLBACK_SCSV and that
> don't support TLS 1.2, and that at least one of {X, Y}  is supported by
> by all TLS-1.2-capable clients that support TLS_FALLBACK_SCSV.
> (Approximately.)

Let's wait with TLS_FALLBACK_SCSV for a minute :-).

To be even more specific, let's simplify the above a bit:

        TLS1.2: X, Y
        TLS1.1: X
        TLS1.0: X
        SSL3.0: RC4-MD5

( SSL3.0 has only RC4-MD5, and RC4-MD5 is not in X or Y. )

If you accept that this is allowed on the server, for the purpose of the 
draft what's the server's maximum protocol version?

1. TLS1.2
2. runtime-dependent, the highest version that a given ClientHello and 
server's set of ciphersuites can possibly negotiate (e.g. ClientHello 
containing only RC4-MD5 --> SSL3.0).

Certainly, the server max. version is TLS1.2 is the simplest of two. 
However, this results in odd behaviour when the server is required to 
fail fallback handshakes with versions that are more secure than it 
could negotiate if TLS_FALLBACK_SCSV was not present.

Example, using the above table:

ClientHello: TLS1.1+RC4-MD5+TLS_FALLBACK_SCSV
Server: MUST fail

v.s.

ClientHello: TLS1.1+RC4-MD5
Server: negotiates SSL3.0+RC4-MD5

Had it been SHOULD fail for the server, the server could have noticed 
that this is not a downgrade that harms the security and allowed the 
handshake to continue.


From nobody Sun Oct 26 00:09:54 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887C61A6FE2 for ; Sun, 26 Oct 2014 00:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMedMhQ80Ww5 for ; Sun, 26 Oct 2014 00:09:35 -0700 (PDT)
Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0FE1A6FD7 for ; Sun, 26 Oct 2014 00:09:35 -0700 (PDT)
Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s9Q79Xpm023830; Sun, 26 Oct 2014 03:09:34 -0400
Date: Sun, 26 Oct 2014 03:09:33 -0400 (EDT)
From: Nikos Mavrogiannopoulos 
To: henrick@streamsec.se
Message-ID: <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com>
In-Reply-To: <544C1BC3.5060204@streamsec.se>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com> <544C1BC3.5060204@streamsec.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.5.82.6]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF29 (Linux)/8.0.6_GA_5922)
Thread-Topic: I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
Thread-Index: ziswt5GOEhOrL6X3rltmMDEqe3CvWg==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PFqK4n0pqxM23_sWWKiVtbaAGtE
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Oct 2014 07:09:37 -0000

----- Original Message -----
> On 2014-10-25 21:51, Nikos Mavrogiannopoulos wrote:
> >> It seems to me the the recommended Client Behavior and Server Behavior
> >> has to be simplified and strengthened, in order for the standard to meet
> >> the security objectives.
> >
> > Could you elaborate on which security objectives are you referring to?
> 
> Second paragraph of section 6.3 Arbitrary groups:
> 
> >    Note that in several known attacks against TLS and SSL
> >    [SECURE-RESUMPTION] [CROSS-PROTOCOL] [SSL3-ANALYSIS], a malicious
> >    server uses a deliberately broken FFDHE group to impersonate the
> >    client to a different server."
> 
> 
> > What is the advantage of that proposal? It is more complex, and a security
> > protocol should strive for simplicity.
> 
> In my view, the current draft leads to a lot more complex
> implementations, compared to my proposal.

Ok, I now understand your point. You suggest using the extension but then keeping
the exact same server key exchange message. That was the initial approach of the
draft if I remember well. 

To be honest I don't see that to be a lot more complex, and the complexity
on the same level as supporting ECDH with named groups and arbitrary groups,
which was deemed reasonable for ECDH. Consistency (with ECDH) is also another
reason to keep the code paths separated.

Note also, that the current approach will simplify a lot an implementation that
doesn't want to keep the old DHE key exchange with arbitrary groups (and unlike
the other key exchanges in TLS, DHE was the most problematic compatibility-wise so
I guess many small implementations would be more than happy to drop it).

regards,
Nikos


From nobody Sun Oct 26 00:14:12 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011031A6FDD for ; Sun, 26 Oct 2014 00:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.612
X-Spam-Level: 
X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQWYFFHUaT90 for ; Sun, 26 Oct 2014 00:14:10 -0700 (PDT)
Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63CA81A6FC8 for ; Sun, 26 Oct 2014 00:14:10 -0700 (PDT)
Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9Q7E8KV024721; Sun, 26 Oct 2014 03:14:08 -0400
Date: Sun, 26 Oct 2014 03:14:08 -0400 (EDT)
From: Nikos Mavrogiannopoulos 
To: Watson Ladd 
Message-ID: <153436771.84597.1414307648093.JavaMail.zimbra@redhat.com>
In-Reply-To: 
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com>  <20141025201642.GA7408@LK-Perkele-VII> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.5.82.6]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF29 (Linux)/8.0.6_GA_5922)
Thread-Topic: I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
Thread-Index: 5nUzKf2l+DBGMtozEnpvD7tWS59dKw==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4rztc3dFj5od8P-r2pocWPbC5K0
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Oct 2014 07:14:12 -0000

----- Original Message -----
> On Sat, Oct 25, 2014 at 1:16 PM, Ilari Liusvaara
>  wrote:
> > On Sat, Oct 25, 2014 at 12:55:58PM -0700, Watson Ladd wrote:
> >> On Sat, Oct 25, 2014 at 12:51 PM, Nikos Mavrogiannopoulos
> >>  wrote:
> >>
> >> > 3. There are known attacks against the current ServerKeyExchange format
> >> > which
> >> > remain applicable if we go this path (a sufficiently long DH
> >> > serverkeyexchange
> >> > message can be parsed as an ECDH serverkeyexchage).
> >>
> >> And 4: session_hash solves the same problem if I understand the
> >> elements of it correctly, and we need it anyway because of this
> >> ambiguity in parsing mentioned above. So do we even need this draft?
> >
> > AFAIK, no, it won't, at least not completely.
> 
> I'm afraid I didn't realize how what I wrote would be read. It seems
> to me that the session_hash doesn't necessarily fix the ambiguity
> issue, but does ensure that sending bad groups will achieve nothing
> for an attacker. Even if we adopt this draft for DHE, session_hash is
> still needed in TLS 1.2. So what does this draft get us, assuming
> session_hash is deployed?

I think it is a bit unproductive to comment without reading the actual
draft. The issue it solves is unrelated to session hash. It is described
in its introduction at
https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-02#section-1

"Traditional TLS [RFC5246] offers a Diffie-Hellman ephemeral (DHE) key
   exchange mode which provides Perfect Forward Secrecy for the
   connection.  The client offers a ciphersuite in the ClientHello that
   includes DHE, and the server offers the client group parameters g and
   p.  If the client does not consider the group strong enough (e.g. if
   p is too small, or if p is not prime, or there are small subgroups),
   or if it is unable to process it for other reasons, it has no
   recourse but to terminate the connection ..."

regards,
Nikos


From nobody Sun Oct 26 01:12:02 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6996C1A6FF5 for ; Sun, 26 Oct 2014 01:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level: 
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wST-UswbUzLe for ; Sun, 26 Oct 2014 01:11:56 -0700 (PDT)
Received: from vsp3.ballou.se (vsp3.ballou.se [91.189.40.101]) by ietfa.amsl.com (Postfix) with SMTP id E952F1A6FF2 for ; Sun, 26 Oct 2014 01:11:55 -0700 (PDT)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp3.ballou.se (Halon Mail Gateway) with ESMTP; Sun, 26 Oct 2014 09:11:51 +0100 (CET)
Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id DA6C41DE4C; Sun, 26 Oct 2014 09:11:51 +0100 (CET)
Message-ID: <544CAC9D.3090909@streamsec.se>
Date: Sun, 26 Oct 2014 09:11:09 +0100
From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com> <544C1BC3.5060204@streamsec.se> <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com>
In-Reply-To: <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/27muncfm-1DYp-0kD_iAoRhIeSs
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: henrick@streamsec.se
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Oct 2014 08:11:58 -0000

On 2014-10-26 08:09, Nikos Mavrogiannopoulos wrote:
> To be honest I don't see that to be a lot more complex, and the complexity
> on the same level as supporting ECDH with named groups and arbitrary groups,
> which was deemed reasonable for ECDH. Consistency (with ECDH) is also another
> reason to keep the code paths separated.

No, ECDHE is different, because you can't implement RFC 4492 (EC cipher 
suites) fully, unless your implementation supports the hello extensions 
and curve negotiation mechanism, and there exists clients that don't 
support arbitrary explicit curves. In the case of DHE, most clients will 
probably only support explicit groups and not support the extension and 
named groups at all, for several years ahead.

Consequently, a server that e.g. only implements secp256r1 encoded as a 
named curve, would stand a fair chance of being interoperable, if it 
simply refuses to negotiate ECDHE cipher suites unless the client sends 
a supported curve extension with this one included. A server that only 
wants to negotiate the FFDHE 3072 bit group could easily encode it as an 
arbitrary group if the client doesn't send the extension (which would 
still happen most of the time), but if the client *does* send the 
extension, then, under the current draft-02, the server would have to 
propagate this information to the server key exchange encoder somehow 
(be it with maps, switches or if-clauses).

> Note also, that the current approach will simplify a lot an implementation that
> doesn't want to keep the old DHE key exchange with arbitrary groups (and unlike
> the other key exchanges in TLS, DHE was the most problematic compatibility-wise so
> I guess many small implementations would be more than happy to drop it).

I don't know about compatibility issues, but rather see a security issue 
that SSL 3.0 up to TLS 1.2 didn't explicitly require the DHE parameters 
to have a bit size greater than or equal to the certificate public key. 
I don't know how common it is for clients that offer DHE cipher suites 
to be able to use the server certificate key for signature verification, 
but unable to compute a DHE handshake using integers of a comparable 
size. I doesn't seem reasonable to expect this to be a problem of such 
magnitude, that the standards should keep an acceptance for low(er) 
security (than necessary) in order to keep interoperability with such 
clients.


From nobody Sun Oct 26 02:08:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FCC1A701A for ; Sun, 26 Oct 2014 02:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Level: 
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oyz55mwn4M6o for ; Sun, 26 Oct 2014 02:08:41 -0700 (PDT)
Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FA231A7016 for ; Sun, 26 Oct 2014 02:08:41 -0700 (PDT)
Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1XiJoU-0000br-Qm; Sun, 26 Oct 2014 10:08:38 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1XiJoU-0004l0-JH; Sun, 26 Oct 2014 10:08:38 +0100
From: Florian Weimer 
To: Andrei Popov 
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com>  <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>         <87egtw84bc.fsf@mid.deneb.enyo.de> 
Date: Sun, 26 Oct 2014 10:08:38 +0100
In-Reply-To:  (Andrei Popov's message of "Sat, 25 Oct 2014 22:05:14 +0000")
Message-ID: <87k33nci5l.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/os8B9DZyUI7WdpCZxrCY1f6ezr0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Oct 2014 09:08:43 -0000

* Andrei Popov:

> Yes, there is some truth in what you say. Downgrade-SCSV is a hack,
> but it will be hard/impossible to convince browser vendors to stop
> doing fallbacks. Perhaps that's because browsers compete on
> interoperability and connectivity, not security?

There's some discussion about disabling fallback in this Mozilla bug,
but I don't know it will turn out because I'm not familiar with
Mozilla's processes:

  

What's odd is that competing on interoperability should also prevent
other useful security enhancements, but it does not happen
consistently: disabling MD5 in certificates, minimum RSA key sizes,
stricter Same-Origin Policy enforcement, click-to-play, and, more
recently, disabling SSL 3.0 by default (only announced by Mozilla so
far).  So it appears that failure-inducing security improvements are
completely off the table simply because vendors fear that users will
just switch to a browser that happens to work.


From nobody Sun Oct 26 16:01:47 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD571A1AEB for ; Sun, 26 Oct 2014 16:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFGjBHFARh31 for ; Sun, 26 Oct 2014 16:01:43 -0700 (PDT)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69BC31A1A36 for ; Sun, 26 Oct 2014 16:01:43 -0700 (PDT)
Received: by mail-la0-f42.google.com with SMTP id gf13so5495437lab.29 for ; Sun, 26 Oct 2014 16:01:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=PAg4/J5hLXCTj9dR8gkp+BvxDVwfdDrRFMRUS0AZ0GY=; b=fceW/1AtTVmhPBNxMOa0CZNvC/v27Qr4oJIlbKn6Zv7huoi2E5ZPDatWS9BqCZ4jti 23cUvTwdDODRGWUA43yunnLsytH18oVGIScMvn68X/bwmhb5tPb6DgalrDPDeSrdnBIE LLvXTlyVlAYHe6le3aZkcxxBQeN0ytRyojZBQDV/Z3nV0DddQbrKvNVt8DhyHzDseP0u goL2F+WiI5cX7OISR1oaE5ZIB1XjLGOaEQ6Xa2AWJyWSiobJeCc1jEpoMiWeWobwUOWa f8mGQ5ZTDKYzur6d+QKrKbbbUSWDzoLnJZ0fiNHCZQ1mT+XQyNSYAZltBMPBVAb3HAyn MfAw==
X-Received: by 10.152.21.9 with SMTP id r9mr19666422lae.76.1414364501738; Sun, 26 Oct 2014 16:01:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.218.145 with HTTP; Sun, 26 Oct 2014 16:01:20 -0700 (PDT)
In-Reply-To: <20141022151623.GA19158@mournblade.imrryr.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <544606E5.2070807@fussenegger.info>  <1659862.HPNNz8lRhl@pintsize.usersys.redhat.com>  <20141022151623.GA19158@mournblade.imrryr.org>
From: David Leon Gil 
Date: Sun, 26 Oct 2014 19:01:20 -0400
Message-ID: 
To: tls@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8iZ1yFKIVFP0X4WIRtTapa_t4F0
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Oct 2014 23:01:45 -0000

On Wed, Oct 22, 2014 at 11:16 AM, Viktor Dukhovni
 wrote:
> On Wed, Oct 22, 2014 at 10:27:32AM -0400, David Leon Gil wrote:
>> There should be a recommended session ticket construction at a 256 bit
>> security strength for privacy to replace RFC 5077 s.4's.
>
> The same construction works just fine with AES-256-CBC, so it is
> merely a matter of updating the draft to recommend AES-256-CBC for
> the encryption.

Yep.

> (I've updated the Postfix default ticket cipher
> to AES-256-CBC as planned for the next release).

This is really excellent to hear. :)

--

The rest is, strictly speaking, irrelevant to session tickets. Unless,
that is, you believe that 128 bits is a reasonable level of protection
for TLS master secrets.

> With somewhat less than 2^25 seconds per year, we're looking at ~2^23
> or ~8 million years of output from such a plant.

Right now, a gigawatt buys you roughly 2^77 linpackflops / year (see
Green500). (I get roughly the same number of symmetric crypto block
ops / year for that hardware -- mostly from the GK110s.)

And by 2020, the top 500 supercomputers will be doing about 2^88
linpackflops / year. See http://www.top500.org/statistics/perfdevel/

(Note that it's undesirable to search the full 2^128 keyspace in any
event; efficiency goes down once you've gotten most of the keys.)

> The use of random IVs or similar "whitening" makes pre-computation substantially less effective.

There's no precomputation. (Storage costs during the attack are <1
block for CTR/GCM, 1 block for ECB, and < 2 blocks for CBC and CFB.)

Ryan: There's very little point in performing this attack with a
quantum computer for TLS; solving dlog is much easier. (Also, the
D-wave thing is not a quantum computer.)


From nobody Sun Oct 26 19:40:50 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCB31A6F44 for ; Sun, 26 Oct 2014 19:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gxLXUk3-5yu for ; Sun, 26 Oct 2014 19:40:47 -0700 (PDT)
Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F01E1A6F13 for ; Sun, 26 Oct 2014 19:40:47 -0700 (PDT)
Received: by mail-qg0-f50.google.com with SMTP id a108so728115qge.9 for ; Sun, 26 Oct 2014 19:40:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=zL+UXLiD/KKdbUZ/cckWq4hVUBcLeQAMQK858LFmazI=; b=aIei7gY5um0QVBp7aPZkAclDFXNkk74MM/KEtBpzA/4zRuT2t6imdRu90Muy+tmAox g3JrHg9VKjZ1ldI6LBG2LorXLqmdwmjUpT2yadw2HvX+KYr8qiAuWml+qwjz1+AvdkTB tD2ciNX46YYHpaFVzfSnf1MHilavGeU6tMB9OlIvz/4lvd6/qWv+RDt4F/pkn4XDPMRc 0GBcbOOh1NwAsMjhOyqr8kAOTjZRP9X4gUG34F+kIxJQZjUwmBJ8TV80kR5MzurIqC+X cH32raW9a8vKpw/qsIKhvA0LwvzVHBmi8r0DiXKBuiUfaclp9dIwvL8CqJ/LwCDpExiM RWdA==
X-Gm-Message-State: ALoCoQmrh7SUSxC0Uz/DprhuE9U0np3o00dYxIIvo4RpD15ENsgLQ/AQNS4eGr9pXiNyRecIM+C2
MIME-Version: 1.0
X-Received: by 10.229.239.74 with SMTP id kv10mr28801392qcb.27.1414377646278;  Sun, 26 Oct 2014 19:40:46 -0700 (PDT)
Received: by 10.96.155.202 with HTTP; Sun, 26 Oct 2014 19:40:46 -0700 (PDT)
X-Originating-IP: [2601:8:b300:a5:7c04:f406:8425:71d0]
Date: Sun, 26 Oct 2014 19:40:46 -0700
Message-ID: 
From: Joseph Salowey 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11347fea2f61b205065e759b
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LmjYIWTFx_hAAqotcI_PX5_Kaeg
Subject: [TLS] November Interim and IETF 91 Meeting details
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 02:40:49 -0000

--001a11347fea2f61b205065e759b
Content-Type: text/plain; charset=UTF-8

Below are the details for the upcoming meetings along with a very drafty
agenda:

TLS November 2014 Interim Meeting

November 9, 2014, 9:30 - 13:30 -  Kahili room

--------------------------------------------------------------------

Agenda (Draft)

---------------------

Focus on TLS 1.3 topics (draft-ietf-tls-tls13
)

   1.

   1.3 Session Resumption
   2.

   1.3 Key Refresh/Client auth
   3.

   1.3 (0-RTT)



IETF 91 TLS Meeting

November 13, 2014, 9 - 11:30 - Coral 5

------------------------------

Agenda (Draft)

--------------------

   1.

   RC4 (if necessary)

draft-ietf-tls-prohibiting-rc4


   1.

   Downgrade SCSV

draft-ietf-tls-downgrade-scsv


   1.

   Session Hash

draft-ietf-tls-session-hash


   1.

   Finite Field DHE negotiation

draft-ietf-tls-negotiated-ff-dhe


   1.

   TLS 1.3 Topics continued/Recap

draft-ietf-tls-tls13 

--001a11347fea2f61b205065e759b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Below are the details for the upcoming meetings along with=
 a very drafty agenda:

TLS November 2014 Interim Meeting
November 9, 201=
4, 9:30 - 13:30 - =C2=A0Kahili room
-----------------------------------------------------------=
---------

Agenda (Draft) 
---------------------
Focus on TL=
S 1.3 topics (draft-ietf-tls-tls13)
  1. 1.3 Session Resumption
  2. 1.3 Key Refresh/Client auth
  3. 1.3=
 (0-RTT)


IETF 91 TLS Meeting 
November 13, 2014, 9 - 11:3=
0 - Coral 5
------------------------------

Agenda (Draft)
-------------=
-------
  1. RC4 (if necessary)
draft-ietf-tls-p=
rohibiting-rc4
  1. Downgrade SCSV
draft-ietf-tls-downgrade-scsv
  1. Session Hash
    2. =

	draft-ietf-tls-session-hash
  1. Finite Field DHE negotiation
=
draft-ietf-tls-negotiated-ff-dhe
  1. TLS 1.3 Topics continued/R=
ecap
draft-ietf-tls-tls13

<=
/div>


--001a11347fea2f61b205065e759b--


From nobody Sun Oct 26 19:58:41 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCC51A6F6D for ; Sun, 26 Oct 2014 19:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJHYzb9P6PkS for ; Sun, 26 Oct 2014 19:58:38 -0700 (PDT)
Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57AC51A1A7E for ; Sun, 26 Oct 2014 19:58:38 -0700 (PDT)
Received: by mail-qc0-f179.google.com with SMTP id o8so1255402qcw.24 for ; Sun, 26 Oct 2014 19:58:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=3t0gd+MpjX6iHlkYlp1h3LWb+MHcULeQXGCuvQzk980=; b=LtvGDG71dybJNkOjc3RZUutXSWAYt6OdQilwwM3mCKSCHxFSs2TlJUFF4LoX7zv/hg LcAOScic7fhm5LW+9BouPzYQRs/DFP4MNJJ7Nhl1O5PhZYlHxH9Qxi6gkTOWjQ1H3OY4 jkBfhcsmZ7BwGobR5FVJ5Pme/XVF+0WTUFoWC18t6PU5BLmXbUf4sXpgL2mjj4eZSqLv 5CepKkhUumfxj6aofXiXyyxIJy6eU3FoXCH/vTqp7Igb1jlyQYA9SU0XLQINvN3YZRHC VsVeAb+DnUgEBMoa1qXFpdhL2+U+kYxPPREe2yI7lDPrIWloek+0Vc7yP+rSm6zbwfxQ B69Q==
X-Gm-Message-State: ALoCoQlOnAJY3wD8m6Em9ych4VvKWWu0vd8LN7Hm8WmfgppcD3kuYv5Js3TG/UpHYnfurqtZhYem
MIME-Version: 1.0
X-Received: by 10.229.79.132 with SMTP id p4mr9448139qck.14.1414378717549; Sun, 26 Oct 2014 19:58:37 -0700 (PDT)
Received: by 10.96.155.202 with HTTP; Sun, 26 Oct 2014 19:58:37 -0700 (PDT)
X-Originating-IP: [67.168.161.122]
Date: Sun, 26 Oct 2014 19:58:37 -0700
Message-ID: 
From: Joseph Salowey 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1134a68c09b00305065eb5de
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uJVqSj0fJxLAkzxMbJU6SctKAqY
Subject: [TLS] Summary of RC4 Discussions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 02:58:40 -0000

--001a1134a68c09b00305065eb5de
Content-Type: text/plain; charset=UTF-8

Judging from the discussion on the list and from the interim meeting report
I think we have consensus to deprecate RC4.  There are different views on
when to deprecate RC4 with the majority view seeming to fall within the
next few years.   I am going to recommend that the IESG proceed with
publication of the draft as is.

Thanks,

Joe

--001a1134a68c09b00305065eb5de
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Judging from the discussion on the list and from the inter=
im meeting report I think we have consensus to deprecate RC4.=C2=A0 There a=
re different views on when to deprecate RC4 with the majority view seeming =
to fall within the next few years. =C2=A0 I am going to recommend that the =
IESG proceed with publication of the draft as is. =C2=A0

Thanks,

Joe


--001a1134a68c09b00305065eb5de--


From nobody Mon Oct 27 01:47:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707E81A8A7B for ; Mon, 27 Oct 2014 01:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level: 
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6G6s4446ioS for ; Mon, 27 Oct 2014 01:47:05 -0700 (PDT)
Received: from vsp6.ballou.se (vsp6.ballou.se [91.189.40.85]) by ietfa.amsl.com (Postfix) with SMTP id 1F9AC1A0020 for ; Mon, 27 Oct 2014 01:47:02 -0700 (PDT)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp6.ballou.se (Halon Mail Gateway) with ESMTP; Mon, 27 Oct 2014 09:46:59 +0100 (CET)
Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 4CC891DE4C; Mon, 27 Oct 2014 09:46:59 +0100 (CET)
Message-ID: <544E0682.30804@streamsec.se>
Date: Mon, 27 Oct 2014 09:46:58 +0100
From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com> <544C1BC3.5060204@streamsec.se> <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com>
In-Reply-To: <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/20bUIPhlN1c8o5QUuiEpB3gj7T0
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: henrick@streamsec.se
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 08:47:07 -0000

On 2014-10-26 08:09, Nikos Mavrogiannopoulos wrote:
> To be honest I don't see that to be a lot more complex, and the complexity
> on the same level as supporting ECDH with named groups and arbitrary groups,
> which was deemed reasonable for ECDH. Consistency (with ECDH) is also another
> reason to keep the code paths separated.

Another thing about this rule:

>    A compatible TLS server that receives the NamedCurve extension with
>    FFDHE codepoints in it, and which selects an FFDHE ciphersuite MUST
>    select one of the offered groups and indicates the choice of groups
>    to the client by sending a specially-formatted ServerDHParams as
>    described below.

Suppose a client offers both ECDHE and FFDHE cipher suites, and does 
send the NamedCurve extension, but with no identifiers the server 
recognizes as FFDHE groups, but with a few identifiers the server 
doesn't recognize at all.

How is the server supposed to tell if:
   1. The client doesn't support named FFDHE groups at all and expects 
the arbitrary encoding of FFDHE server key exchange messages, or
   2. The client supports only a few named FFDHE groups defined in a 
later revision of the standard that the server hasn't yet implemented, 
meaning the server ideally MUST NOT use the arbitrary encoding of FFDHE 
groups, but rather pick other cipher suites?

This is a dilemma that implementors might decide to circumvent in 
complex and undesirable ways.


From nobody Mon Oct 27 03:47:50 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74111A900B for ; Mon, 27 Oct 2014 03:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXYAP3nPLL0Z for ; Mon, 27 Oct 2014 03:47:47 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94DB41A9087 for ; Mon, 27 Oct 2014 03:47:46 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9RAPthA027585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 27 Oct 2014 06:25:55 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9RAPpu8029425 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2014 06:25:54 -0400
Message-ID: <1414405551.2543.8.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: henrick@streamsec.se
Date: Mon, 27 Oct 2014 11:25:51 +0100
In-Reply-To: <544E0682.30804@streamsec.se>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com> <544C1BC3.5060204@streamsec.se> <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com> <544E0682.30804@streamsec.se>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5mdETrDI16KhMqewpLRVnpagCBg
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 10:47:49 -0000

On Mon, 2014-10-27 at 09:46 +0100, Henrick Hellström wrote:
> On 2014-10-26 08:09, Nikos Mavrogiannopoulos wrote:
> > To be honest I don't see that to be a lot more complex, and the complexity
> > on the same level as supporting ECDH with named groups and arbitrary groups,
> > which was deemed reasonable for ECDH. Consistency (with ECDH) is also another
> > reason to keep the code paths separated.
> 
> Another thing about this rule:
> 
> >    A compatible TLS server that receives the NamedCurve extension with
> >    FFDHE codepoints in it, and which selects an FFDHE ciphersuite MUST
> >    select one of the offered groups and indicates the choice of groups
> >    to the client by sending a specially-formatted ServerDHParams as
> >    described below.
> 
> Suppose a client offers both ECDHE and FFDHE cipher suites, and does 
> send the NamedCurve extension, but with no identifiers the server 
> recognizes as FFDHE groups, but with a few identifiers the server 
> doesn't recognize at all.
> How is the server supposed to tell if:
>    1. The client doesn't support named FFDHE groups at all and expects 
> the arbitrary encoding of FFDHE server key exchange messages, or

All the server needs to know is the common FFDHE groups they support.
And that it apparent in that case. None.

If they have no common groups the server SHOULD NOT negotiate DHE
according to the current draft, so no dilemma here.

>    2. The client supports only a few named FFDHE groups defined in a 
> later revision of the standard that the server hasn't yet implemented, 
> meaning the server ideally MUST NOT use the arbitrary encoding of FFDHE 
> groups, but rather pick other cipher suites?

I think the situation is similar as above. The intersection of the
supported FFDHE groups is empty, thus according to the
draft-ietf-tls-negotiated-ff-dhe a compliant server should not select
the DHE ciphersuites at all. If he selected DHE ciphersuites, it is a
legacy server that doesn't support the draft. So for the server, the
decisions are straightforward as far as I understand.

A client though will have to decide on whether a legacy server is seen,
or a compliant to ffdhe draft, based on the format of ServerKeyExchange.
That's why I suggested to make them sufficiently distinct.

regards,
Nikos



From nobody Mon Oct 27 03:58:30 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061671A6F2E for ; Mon, 27 Oct 2014 03:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level: 
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ru5Q7I0OhaPL for ; Mon, 27 Oct 2014 03:58:22 -0700 (PDT)
Received: from vsp5.ballou.se (vsp5.ballou.se [91.189.40.84]) by ietfa.amsl.com (Postfix) with SMTP id 521AF1A1AB2 for ; Mon, 27 Oct 2014 03:58:21 -0700 (PDT)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp5.ballou.se (Halon Mail Gateway) with ESMTP; Mon, 27 Oct 2014 11:58:18 +0100 (CET)
Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id B0B4F1DE4C; Mon, 27 Oct 2014 11:58:18 +0100 (CET)
Message-ID: <544E254A.3020501@streamsec.se>
Date: Mon, 27 Oct 2014 11:58:18 +0100
From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com>	 <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se>	 <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com>	 <544C1BC3.5060204@streamsec.se>	 <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com>	 <544E0682.30804@streamsec.se> <1414405551.2543.8.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1414405551.2543.8.camel@dhcp-2-127.brq.redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lyXOyv8kFvlXoJaJ7pLJet8zClQ
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: henrick@streamsec.se
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 10:58:25 -0000

On 2014-10-27 11:25, Nikos Mavrogiannopoulos wrote:
> On Mon, 2014-10-27 at 09:46 +0100, Henrick Hellström wrote:
>> Suppose a client offers both ECDHE and FFDHE cipher suites, and does
>> send the NamedCurve extension, but with no identifiers the server
>> recognizes as FFDHE groups, but with a few identifiers the server
>> doesn't recognize at all.
>> How is the server supposed to tell if:
>>     1. The client doesn't support named FFDHE groups at all and expects
>> the arbitrary encoding of FFDHE server key exchange messages, or
>
> All the server needs to know is the common FFDHE groups they support.
> And that it apparent in that case. None.
>
> If they have no common groups the server SHOULD NOT negotiate DHE
> according to the current draft, so no dilemma here.

That is NOT what the draft says. The draft does NOT prohibit the server 
to negotiate an FFDHE cipher suite, when negotiating with a 
non-compatible client. All the draft says is that the server shouldn't 
send specially formatted server_key_exchange messages to non-compatible 
clients, which makes sense.-


>>     2. The client supports only a few named FFDHE groups defined in a
>> later revision of the standard that the server hasn't yet implemented,
>> meaning the server ideally MUST NOT use the arbitrary encoding of FFDHE
>> groups, but rather pick other cipher suites?
>
> I think the situation is similar as above.

Perhaps I wasn't clear. This isn't a second situation. It is just a 
second way the server might interpret the SAME ambiguous situation.


> A client though will have to decide on whether a legacy server is seen,
> or a compliant to ffdhe draft, based on the format of ServerKeyExchange.
> That's why I suggested to make them sufficiently distinct.

FWIW, the real problem here is RFC 4492. There was no ambiguity in TLS 
1.0, because the ServerKeyExchange could only contain two kinds of 
messages, one with two large integers (a ServerRSAParams) or one with 
three large integers (a ServerDHParams). RFC 4492 introduced the 
ambiguity. Can anyone think of a way to fix it, without forcing Named 
FFDHE compatible servers to negotiate RSA cipher suites instead of DHE 
cipher suites with legacy clients? Is that even a good idea? (That was a 
rhetorical question.)


From nobody Mon Oct 27 04:07:12 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62BF1A8A61 for ; Mon, 27 Oct 2014 04:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8dn9SqYC1VG for ; Mon, 27 Oct 2014 04:07:05 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF421A89FF for ; Mon, 27 Oct 2014 04:07:05 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9RB74KE023828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 27 Oct 2014 07:07:04 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9RB71aj017754 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2014 07:07:03 -0400
Message-ID: <1414408020.2543.13.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: henrick@streamsec.se
Date: Mon, 27 Oct 2014 12:07:00 +0100
In-Reply-To: <544E254A.3020501@streamsec.se>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com> <544C1BC3.5060204@streamsec.se> <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com> <544E0682.30804@streamsec.se> <1414405551.2543.8.camel@dhcp-2-127.brq.redhat.com> <544E254A.3020501@streamsec.se>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PIY3ClxrPQbL6cnF9hzgF6sXd0Y
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 11:07:09 -0000

On Mon, 2014-10-27 at 11:58 +0100, Henrick Hellström wrote:
> On 2014-10-27 11:25, Nikos Mavrogiannopoulos wrote:
> > On Mon, 2014-10-27 at 09:46 +0100, Henrick Hellström wrote:
> >> Suppose a client offers both ECDHE and FFDHE cipher suites, and does
> >> send the NamedCurve extension, but with no identifiers the server
> >> recognizes as FFDHE groups, but with a few identifiers the server
> >> doesn't recognize at all.
> >> How is the server supposed to tell if:
> >>     1. The client doesn't support named FFDHE groups at all and expects
> >> the arbitrary encoding of FFDHE server key exchange messages, or
> >
> > All the server needs to know is the common FFDHE groups they support.
> > And that it apparent in that case. None.
> >
> > If they have no common groups the server SHOULD NOT negotiate DHE
> > according to the current draft, so no dilemma here.
> 
> That is NOT what the draft says. The draft does NOT prohibit the server 
> to negotiate an FFDHE cipher suite, when negotiating with a 
> non-compatible client.

We may be referring to different versions of the draft. The current
draft says:
"If the extension is present, none of the client's offered groups are
   acceptable by the server, and none of the client's proposed non-FFDHE
   ciphersuites are acceptable to the server, the server SHOULD end the
   connection with a fatal TLS alert of type insufficient_security."

This does explicitly prohibit the server to negotiate an FFDHE cipher
suite if the extension is present.

> > A client though will have to decide on whether a legacy server is seen,
> > or a compliant to ffdhe draft, based on the format of ServerKeyExchange.
> > That's why I suggested to make them sufficiently distinct.
> FWIW, the real problem here is RFC 4492. There was no ambiguity in TLS 
> 1.0, because the ServerKeyExchange could only contain two kinds of 
> messages, one with two large integers (a ServerRSAParams) or one with 
> three large integers (a ServerDHParams). RFC 4492 introduced the 
> ambiguity. Can anyone think of a way to fix it, without forcing Named 
> FFDHE compatible servers to negotiate RSA cipher suites instead of DHE 
> cipher suites with legacy clients? Is that even a good idea? (That was a 
> rhetorical question.)

A way to fix that for the ffdhe draft would be to introduce a two-byte
type that is on purpose large (eg. values like 0xff 0xfa).

regards,
Nikos



From nobody Mon Oct 27 04:37:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87F01A90B7 for ; Mon, 27 Oct 2014 04:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level: 
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDC4cjvsW_WM for ; Mon, 27 Oct 2014 04:37:04 -0700 (PDT)
Received: from vsp5.ballou.se (vsp5.ballou.se [91.189.40.84]) by ietfa.amsl.com (Postfix) with SMTP id C03391A9095 for ; Mon, 27 Oct 2014 04:37:03 -0700 (PDT)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp5.ballou.se (Halon Mail Gateway) with ESMTP; Mon, 27 Oct 2014 12:37:01 +0100 (CET)
Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 32B481DE4C; Mon, 27 Oct 2014 12:37:01 +0100 (CET)
Message-ID: <544E2E5D.4000805@streamsec.se>
Date: Mon, 27 Oct 2014 12:37:01 +0100
From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com>		 <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se>		 <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com>		 <544C1BC3.5060204@streamsec.se>		 <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com>		 <544E0682.30804@streamsec.se>	 <1414405551.2543.8.camel@dhcp-2-127.brq.redhat.com>	 <544E254A.3020501@streamsec.se> <1414408020.2543.13.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1414408020.2543.13.camel@dhcp-2-127.brq.redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DOeUbaloFBQV21HeQBSz1PqqyyY
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: henrick@streamsec.se
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 11:37:06 -0000

On 2014-10-27 12:07, Nikos Mavrogiannopoulos wrote:
> We may be referring to different versions of the draft. The current
> draft says:
> "If the extension is present, none of the client's offered groups are
>     acceptable by the server, and none of the client's proposed non-FFDHE
>     ciphersuites are acceptable to the server, the server SHOULD end the
>     connection with a fatal TLS alert of type insufficient_security."
>
> This does explicitly prohibit the server to negotiate an FFDHE cipher
> suite if the extension is present.

OK, I stand corrected, I didn't interpret that paragraph that way. It 
starts with

>    If a compatible TLS server receives a NamedCurves extension from a
>    client that includes any FFDHE groups


...so I interpreted the whole paragraph as referring to extensions the 
server is able to recognize as including BOTH named elliptic curves AND 
named ffdhe groups. If it really says that a Named FFDHE compatible 
server MUST NOT negotiate DHE cipher suites with clients that implement 
RFC 4492, but not the Named FFDHE standard, that should be stated 
explicitly.

It does however strike me as odd that, as a consequence, a named FFDHE 
compatible server, would still be allowed to negotiate DHE cipher suites 
with legacy clients that do not even implement RFC 4492, but not with 
legacy clients that implement DHE in the exact same way, but also 
support a few weak elliptic curves.


From nobody Mon Oct 27 05:11:03 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EF81A9238 for ; Mon, 27 Oct 2014 05:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD5SrlcKwUEj for ; Mon, 27 Oct 2014 05:10:50 -0700 (PDT)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1124C1A9236 for ; Mon, 27 Oct 2014 05:10:16 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 3168B1887E6; Mon, 27 Oct 2014 14:10:12 +0200 (EET)
Date: Mon, 27 Oct 2014 14:10:12 +0200
From: Ilari Liusvaara 
To: Nikos Mavrogiannopoulos 
Message-ID: <20141027121012.GA10631@LK-Perkele-VII>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com> <544C1BC3.5060204@streamsec.se> <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com> <544E0682.30804@streamsec.se> <1414405551.2543.8.camel@dhcp-2-127.brq.redhat.com> <544E254A.3020501@streamsec.se> <1414408020.2543.13.camel@dhcp-2-127.brq.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1414408020.2543.13.camel@dhcp-2-127.brq.redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7zUqrgB4N-LrRnoH-t-dY2pPUQc
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 12:10:58 -0000

On Mon, Oct 27, 2014 at 12:07:00PM +0100, Nikos Mavrogiannopoulos wrote:
> On Mon, 2014-10-27 at 11:58 +0100, Henrick Hellström wrote:
> >
> > FWIW, the real problem here is RFC 4492. There was no ambiguity in TLS 
> > 1.0, because the ServerKeyExchange could only contain two kinds of 
> > messages, one with two large integers (a ServerRSAParams) or one with 
> > three large integers (a ServerDHParams). RFC 4492 introduced the 
> > ambiguity. Can anyone think of a way to fix it, without forcing Named 
> > FFDHE compatible servers to negotiate RSA cipher suites instead of DHE 
> > cipher suites with legacy clients? Is that even a good idea? (That was a 
> > rhetorical question.)
> 
> A way to fix that for the ffdhe draft would be to introduce a two-byte
> type that is on purpose large (eg. values like 0xff 0xfa).

Basically, you want to:
1) ECDHE SKE to not be interpretable as FFDHE SKE.
2) FFDHE SKE to blow up when interpretted as ECDHE SKE.
3) FFDHE SKE to blow up when interpretted as DHE SKE (including legacy software).


If the first byte of FFDHE SKE has to be 00, that takes care of 1) and 2),
because first byte of ECDHE SKE is the curve type, and curve type 0 is
not valid.

3) Is nastier issue. AFAICT, with such misinterpretation, not even session_hash
will save you.

One way (not necressarily good) would be to encode ServerDHParams as
00 01 00 NOT(grpid). If one tries to parse this as DHE, one gets p=0 and length
of g being ~65,000 bytes (pretty certainly overflowing the message).


-Ilari


From nobody Mon Oct 27 05:53:12 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64A01A9103 for ; Mon, 27 Oct 2014 05:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level: 
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mzjUCjpCsNz for ; Mon, 27 Oct 2014 05:52:54 -0700 (PDT)
Received: from vsp5.ballou.se (vsp5.ballou.se [91.189.40.84]) by ietfa.amsl.com (Postfix) with SMTP id 957671A8AE5 for ; Mon, 27 Oct 2014 05:52:52 -0700 (PDT)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp5.ballou.se (Halon Mail Gateway) with ESMTP; Mon, 27 Oct 2014 13:52:49 +0100 (CET)
Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 74DAA1DE4C; Mon, 27 Oct 2014 13:52:49 +0100 (CET)
Message-ID: <544E4021.9010906@streamsec.se>
Date: Mon, 27 Oct 2014 13:52:49 +0100
From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ilari Liusvaara ,  Nikos Mavrogiannopoulos 
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com> <544C1BC3.5060204@streamsec.se> <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com> <544E0682.30804@streamsec.se> <1414405551.2543.8.camel@dhcp-2-127.brq.redhat.com> <544E254A.3020501@streamsec.se> <1414408020.2543.13.camel@dhcp-2-127.brq.redhat.com> <20141027121012.GA10631@LK-Perkele-VII>
In-Reply-To: <20141027121012.GA10631@LK-Perkele-VII>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Am2hTQ2g_zUF6Ot4PG8h8Te4W0I
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: henrick@streamsec.se
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 12:52:55 -0000

On 2014-10-27 13:10, Ilari Liusvaara wrote:
> One way (not necressarily good) would be to encode ServerDHParams as
> 00 01 00 NOT(grpid). If one tries to parse this as DHE, one gets p=0 and length
> of g being ~65,000 bytes (pretty certainly overflowing the message).

IMHO, a much better (and fully backwards compatible) way would be to 
deprecate the two explicit ECCurveTypes. A named_curve will start with 
03 xx xx  <1..2^8-1>, which cannot be parsed as legacy DHE without 
overflowing into the signature section and making the verification fail. 
Conversely, legacy DHE would have to contain a dh_p that is at least 
6144 bits in order for the ServerDHParams to start with 03, which would 
make it impossible for the signature to start at the right position for 
it to be verified by the ServerECDHParams parser.


From SRS0=0P51=7S=acm.org=bmoeller@srs.kundenserver.de  Mon Oct 27 07:53:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833831A87AD for ; Mon, 27 Oct 2014 07:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUH4wkPxAzR2 for ; Mon, 27 Oct 2014 07:53:09 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4AB1A0023 for ; Mon, 27 Oct 2014 07:53:08 -0700 (PDT)
Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0MQLgi-1XWcZw1vps-00Toxx; Mon, 27 Oct 2014 15:53:04 +0100
Received: by mail-yk0-f171.google.com with SMTP id 20so396865yks.30 for ; Mon, 27 Oct 2014 07:53:03 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.191.230 with SMTP id g66mr22970470yhn.27.1414421583408;  Mon, 27 Oct 2014 07:53:03 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Mon, 27 Oct 2014 07:53:03 -0700 (PDT)
In-Reply-To: <544C6C00.3070903@brainhub.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5449E969.9000800@brainhub.org>  <544AB4B4.2010305@brainhub.org>  <544B5764.9020006@brainhub.org>  <544B5D82.2080900@brainhub.org>  <544BFCED.9080904@brainhub.org>  <544C6C00.3070903@brainhub.org>
Date: Mon, 27 Oct 2014 15:53:03 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=20cf305b10820ab531050668b023
X-Provags-ID: V02:K0:M6mmMZ2FtF+4/iie8efj29EtDKSdC8FqPbZ/cp8w0ql zSn++RimzWmNIkyV8XDk1XWHjOHDjOOaysuVbvfNeeC/BOBBd/ WtU5ToX36NqguXGSRp9HpNGLGwgcQeo+J1gWPqYWmtfgoeLIj/ Xw6YU6p4a8ZdRpY6CPpSpE5ctk/eXlubN0A8nHiPtSpWSMU6RG Wnz7UwMsAwwHgy/CpNfbaomAeWwHrLOMKdtUFMJO6CE8KTMPXE CC81t+14+AvhdxziheTFGcMJdgbxKsVDgiGiTJfND2OM7/x04C AZYn/ulyblEU2e79M6X0jLafgnDoftIAJzK5464cAw2nlsJG7m 1OLJtjCTyavHnj+ULAGfOYt85s3GayCXf8x/U09ab5sjW7Ws8S 0sykq3CkTgZSKGOj484WKUDMGvEK79fwUmQvU22eOmzYSwGVqQ 6URDL
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d_KD4oSvEXQlfxS_pq-zm9bZstQ
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 14:54:37 -0000

--20cf305b10820ab531050668b023
Content-Type: text/plain; charset=UTF-8

Andrey Jivsov :

To be even more specific, let's simplify the above a bit:
>
>        TLS1.2: X, Y

[...]

> If you accept that this is allowed on the server, for the purpose of the
> draft what's the server's maximum protocol version?
>

Very clearly it is TLS 1.2, but I'll make it clearer in the next version of
the I-D to avoid any ambiguity.

Note that in fallback retries, clients might omit cipher suites (that don't
work with the older protocol version).  We don't want to the server to try
to be clever then and say "Well, this Client Hello doesn't look a fallback
after all because I only support these ciphers with older protocols".



> [...] However, this results in odd behaviour when the server is required
> to fail fallback handshakes with versions that are more secure than it
> could negotiate if TLS_FALLBACK_SCSV was not present.
>

Maybe so, but I can live with that: this is not an arbitrary restriction,
but it follows from rules that serve the purpose they are designed for, and
it does not affect servers that follow the TLS specification.

Bodo

--20cf305b10820ab531050668b023
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Andr=
ey Jivsov <crypto@brainhub.org>:


To be even more specific, let's simplify the above a bit:



=C2=A0 =C2=A0 =C2=A0 =C2=A0TLS1.2: X, Y
[...]=C2=A0=


If you accept that this is allowed on the server, for the purpose of the dr=
aft what's the server's maximum protocol version?
<=
div>
Very clearly it is TLS 1.2, but I'll make it clearer=
 in the next version of the I-D to avoid any ambiguity.

Note that in fallback retries, clients might omit cipher suites (that=
 don't work with the older protocol version).=C2=A0 We don't want t=
o the server to try to be clever then and say "Well, this Client Hello=
 doesn't look a fallback after all because I only support these ciphers=
 with older protocols".

=C2=A0

[...] However, this results in odd behaviour when the server is required to=
 fail fallback handshakes with versions that are more secure than it could =
negotiate if TLS_FALLBACK_SCSV was not present.

Maybe so, but I can live with that: this is not an arbitrary restr=
iction, but it follows from rules that serve the purpose they are designed =
for, and it does not affect servers that follow the TLS specification.

Bodo



--20cf305b10820ab531050668b023--


From nobody Mon Oct 27 08:22:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1E71ACE17 for ; Mon, 27 Oct 2014 08:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSxdItYBIvDJ for ; Mon, 27 Oct 2014 08:22:30 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED2D1ACDDF for ; Mon, 27 Oct 2014 08:22:26 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 3B0C5F984 for ; Mon, 27 Oct 2014 11:22:23 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 7B6A925912; Mon, 27 Oct 2014 11:22:14 -0400 (EDT)
From: Daniel Kahn Gillmor 
To: tls@ietf.org
In-Reply-To: <544C6C00.3070903@brainhub.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5449E969.9000800@brainhub.org>  <544AB4B4.2010305@brainhub.org>  <544B5764.9020006@brainhub.org>  <544B5D82.2080900@brainhub.org>  <544BFCED.9080904@brainhub.org>  <544C6C00.3070903@brainhub.org>
User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu)
Date: Mon, 27 Oct 2014 11:22:10 -0400
Message-ID: <87a94hwna5.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e-6Goc2ns-Udi6LWAXtnxidS-Pk
Subject: Re: [TLS] Working Group Last Call for	draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 15:22:32 -0000

--=-=-=
Content-Type: text/plain

On Sat 2014-10-25 23:35:28 -0400, Andrey Jivsov wrote:
> Let's wait with TLS_FALLBACK_SCSV for a minute :-).
>
> To be even more specific, let's simplify the above a bit:
>
>         TLS1.2: X, Y
>         TLS1.1: X
>         TLS1.0: X
>         SSL3.0: RC4-MD5
>
> ( SSL3.0 has only RC4-MD5, and RC4-MD5 is not in X or Y. )
 [...]
> Example, using the above table:
>
> ClientHello: TLS1.1+RC4-MD5+TLS_FALLBACK_SCSV
> Server: MUST fail
>
> v.s.
>
> ClientHello: TLS1.1+RC4-MD5
> Server: negotiates SSL3.0+RC4-MD5

I think you've just demonstrated that the server is misconfigured in
this example.

Because of its misconfiguration, the server has selected SSL3.0 when it
could have selected TLS1.1.

(this scenario might have more nuance if we're talking about a TLS 1.3
specification that doesn't permit negotiation of RC4-MD5, but that's not
the scenario painted above)

----

In general, i don't have a lot of sympathy for the complaint that a
network failure causes fallback negotiation, which might fail.  Outside
of TLS, when a network failure causes a TCP session to abort, the
connection fails anyway.

We should have guidance to the implementer of any fallback dance that
the receipt of an inappropriate_fallback alert means you should clear
your notion of whether a given host needs a fallback.

In a browser context, this means that the user clicks "reload", and they
get a new try at the connection.  This is something users are familiar
with in other network-glitch scenarios.

     --dkg

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQJ8BAEBCgBmBQJUTmMjXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcf3AQANA1CGrcGZDFh+JDFkXvclVQ
js0R7lhgwi/fYeJo7RopK0lqE2dfmS+af08w+bI+agb0fiqmVJ4ARZWBg3hIqHA8
KBo7hkZtozSNqTLkmneHvtoZuwWGgtjeJKnao0jdKGhgPageW7G2DliIhLFWsIb1
on5FJO2cakIUKiYmeCoq+axZ/tl8loyoDm+hZXIhWbjDFqHHsJU+lF4j3RNcaju8
fFHsb9TbsBj2IJq2OdJo43tQtIBH0dM/tGRJpaqrEqVqz7BLRO9VVTZAhrLsw6TB
fAeMBC/W4YG6UzAU+XqA1SAtMD2830AmGItBS1Cyhe7nBEkRxsrHDkyepWHvvBtm
7qMIu03lyViFzxWFfvtcMz/wgpLQzmT8BvDc7CCDr1NUDRUzIVRC2mCMxG7qny05
wQJ749VhvVUTXjwpH2vh+j1qHn6BqwnbnyFCV9v1ZFL/4/enVj3c42hAE6xaznNh
/i4JeqWtTsACDcqI9mfBVbSFuatMm29ihkGBIg12wBGdhRNo19RdwrROxNvD7c8d
VLnTbMTT5ZrqT14vgTs3UJEkvhViYnvywPP37+SlvbeJSZ+9x71THtAbIkmqBHeu
GM2otgDuLiEjZS/ouFWcHh8y74bbhh1liurDw+f3kgAev96qIAUZQ62Af40/yenx
U7vYl74QNHTlW6dRqjO5
=BKcs
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Oct 27 10:19:09 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618671A0164 for ; Mon, 27 Oct 2014 10:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOtVH0LVZyDk for ; Mon, 27 Oct 2014 10:19:04 -0700 (PDT)
Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33DAB1A0154 for ; Mon, 27 Oct 2014 10:19:04 -0700 (PDT)
Received: by mail-qg0-f51.google.com with SMTP id j5so2000157qga.24 for ; Mon, 27 Oct 2014 10:19:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=P2pEggLnzSipzaEx/l0KdvJpWn6G3SI8YLyo6uSN4uA=; b=bMmVMA82TNYMUpxg9RR6tS3H0/CP6DyO77gWDB1B0gwpudBKJH8LfMAa/iWTvg9Cg1 4/Y1GHtFiZ+t7ti4jOkgQTGLVpNNEKIhjrjCZxJfBm3qofxDmwH+3iHZyLbhkXxqueZb xs2nEY4dnwmRWUzkl3FWZyhvrZBCXEQLUnVR0RCpD8NXV1pBRj6Lyosu7qU1h/VqtsEG hGvBEXJUl9FE6zR813iIU4PZ7FplrmF8y2KXcHM8CHUGzyfMyGXXv5kIpBBiI1Iu2lMA qJAXp19XKzUTXYX0T5oRiDAz8I76rDJIGIkzl+/h3iRRY6GiN6nXObOo7Kz4ccKqoqBH VScg==
X-Gm-Message-State: ALoCoQnCJqnsvWFcRWXauZ1GQCquz9EOxxg079wKfUZmrF4RjstF/4ptp35Xo6KEpTOsXuWv+sZ0
X-Received: by 10.140.105.164 with SMTP id c33mr32765811qgf.11.1414430343347;  Mon, 27 Oct 2014 10:19:03 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:e7:95c6:bde0:689a:9257? ([2601:a:2a00:e7:95c6:bde0:689a:9257]) by mx.google.com with ESMTPSA id 68sm11601144qgj.34.2014.10.27.10.19.02 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Oct 2014 10:19:02 -0700 (PDT)
Message-ID: <544E7EA7.7040908@nthpermutation.com>
Date: Mon, 27 Oct 2014 13:19:35 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060102010104020504060009"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DRzN9PjwaBp_ZEEqRJ3NosNRhA0
Subject: Re: [TLS] November Interim and IETF 91 Meeting details
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 17:19:07 -0000

This is a multi-part message in MIME format.
--------------060102010104020504060009
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Joe -

At the beginning of the normal meeting (and basically every normal 
meeting), could we please make sure we do at least a 15-20 minute review 
of the open issues list?

Thanks - Mike


On 10/26/2014 10:40 PM, Joseph Salowey wrote:
> Below are the details for the upcoming meetings along with a very 
> drafty agenda:
>
> TLS November 2014 Interim Meeting
>
> November 9, 2014, 9:30 - 13:30 -  Kahili room
>
> --------------------------------------------------------------------
>
>
> Agenda (Draft)
>
> ---------------------
>
> Focus on TLS 1.3 topics (draft-ietf-tls-tls13 
> )
>
> 1.
>
>     1.3 Session Resumption
>
> 2.
>
>     1.3 Key Refresh/Client auth
>
> 3.
>
>     1.3 (0-RTT)
>
>
>
> IETF 91 TLS Meeting
>
> November 13, 2014, 9 - 11:30 - Coral 5
>
> ------------------------------
>
>
> Agenda (Draft)
>
> --------------------
>
> 1.
>
>     RC4 (if necessary)
>
> draft-ietf-tls-prohibiting-rc4 
> 
>
> 2.
>
>     Downgrade SCSV
>
> draft-ietf-tls-downgrade-scsv 
> 
>
> 3.
>
>     Session Hash
>
> draft-ietf-tls-session-hash 
> 
>
> 4.
>
>     Finite Field DHE negotiation
>
> draft-ietf-tls-negotiated-ff-dhe 
> 
>
> 5.
>
>     TLS 1.3 Topics continued/Recap
>
> draft-ietf-tls-tls13 
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--------------060102010104020504060009
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Joe -

      

      At the beginning of the normal meeting (and basically every normal
      meeting), could we please make sure we do at least a 15-20 minute
      review of the open issues list?  

      

      Thanks - Mike

      

      

      On 10/26/2014 10:40 PM, Joseph Salowey wrote:

    

    

      
Below are the details for the upcoming meetings
        along with a very drafty agenda:
        


        

        

            
TLS
                November 2014 Interim Meeting

            
November
                9, 2014, 9:30 - 13:30 -  Kahili
                room

            
--------------------------------------------------------------------

            

            
Agenda
                (Draft) 

            
---------------------

            
Focus
                on TLS 1.3 topics (draft-ietf-tls-tls13)

            
    
              
  1. 
                
    1.3
                    Session Resumption
    
              
    2. 
              
  2. 
                
    1.3
                    Key Refresh/Client auth
    
              
    3. 
              
  3. 
                
    1.3
                    (0-RTT)
    
              
    4. 
            

            

            

            
IETF
                91 TLS Meeting 

            
November
                13, 2014, 9 - 11:30 - Coral 5

            
------------------------------

            

            
Agenda
                (Draft)

            
--------------------

            
    
              
  1. 
                
    RC4
                    (if necessary)
    
              
    2. 
            

            
draft-ietf-tls-prohibiting-rc4

            
    
              
  1. 
                
    Downgrade
                    SCSV
    
              
    2. 
            

            
draft-ietf-tls-downgrade-scsv

            
    
              
  1. 
                
    Session
                    Hash
    
              
    2. 
            

            
 draft-ietf-tls-session-hash

            
    
              
  1. 
                
    Finite
                    Field DHE negotiation
    
              
    2. 
            

            
draft-ietf-tls-negotiated-ff-dhe

            
    
              
  1. 
                
    TLS
                    1.3 Topics continued/Recap
    
              
    2. 
            

            
draft-ietf-tls-tls13

            

          

      

      

      

      

      
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


    

    

  


--------------060102010104020504060009--


From nobody Mon Oct 27 11:23:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA761A9044 for ; Mon, 27 Oct 2014 11:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4-cctzExbiW for ; Mon, 27 Oct 2014 11:22:37 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id F20A01A8EA9 for ; Mon, 27 Oct 2014 11:21:01 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 975F5F984 for ; Mon, 27 Oct 2014 14:20:56 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id ECC50258FB; Mon, 27 Oct 2014 14:20:46 -0400 (EDT)
From: Daniel Kahn Gillmor 
To: tls@ietf.org
In-Reply-To: <544E2E5D.4000805@streamsec.se>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com> <544C1BC3.5060204@streamsec.se> <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com> <544E0682.30804@streamsec.se> <1414405551.2543.8.camel@dhcp-2-127.brq.redhat.com> <544E254A.3020501@streamsec.se> <1414408020.2543.13.camel@dhcp-2-127.brq.redhat.com> <544E2E5D.4000805@streamsec.se>
User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu)
Date: Mon, 27 Oct 2014 14:20:43 -0400
Message-ID: <874mupwf0k.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fjo3iueH9lLkQXoP4HxFj9uv4D8
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 18:22:43 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon 2014-10-27 07:37:01 -0400, Henrick Hellstr=C3=B6m wrote:
> It does however strike me as odd that, as a consequence, a named FFDHE=20
> compatible server, would still be allowed to negotiate DHE cipher suites=
=20
> with legacy clients that do not even implement RFC 4492, but not with=20
> legacy clients that implement DHE in the exact same way, but also=20
> support a few weak elliptic curves.

hm, yes, i agree that this is a bad outcome, and as of -02 that does
appear to be the consequence of the draft.  Thanks for pointing this
out, Henrick.

To be clear, i think the problem is:

 * a compatible server might see a client send a DHE ciphersuite and the
   NamedCurves extension, but with at least one identified NamedCurve
   that the server doesn't know.

 * In this case, the server cannot distinguish the following two peers:

    A) the client implements this draft, but only implements an unusual
       FFDHE that the server has never heard of.

    B) the client does not implement with this draft and happens to
       implement an elliptic curve that the server has never heard of.

 * The right logic here is that the server SHOULD NOT select DHE for
   client A, but MAY select DHE for client B, as when interoperating
   with any other legacy client implementation.  But the server can't
   distinguish between these cases.


I think there needs to be explicit signalling from the client that it
understands known FFDHE groups, so that a server can distinguish between
these cases.

I see three ways to achieve this goal:

 0) reintroduce an explicit (contentless) ClientHello extension that
    means "i understand FFDHE named groups"

 1) allocate a single codepoint in the named groups registry that means
    "i understand FFDHE named groups" but is not a negotiable group

 2) carve out a range of codepoints in the named groups registry that
    will be used only for FFDHE named groups (and no other codepoints in
    that registry will have FFDHE).  This way, servers can recognize a
    named FFDHE group, even if they don't know what it is.

(0) seems like a simple approach, though it introduces a bit of redundancy
that could cause weirdness -- what does it mean if the ClientHello
extension is not present, but an FFDHE group exists in the NamedCurves
extension, for example?

(1) smells a lot like the SCSV approach we've been trying (and failing)
to avoid using in other contexts, though it happens in NamedCurves,
instead of in the ciphersuite list.  I'd really rather avoid this kind
of hackery.

(2) seems like it might be the simplest approach.  For example, if the
value is within [256,287]) then the NamedCurve is FFDHE.  This wouldn't
be the first time that an IANA registry had range registration
procedures like this, see e.g.  ARP Hardware Types:

https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml#arp-pa=
rameters-2

It does place a smaller permanent cap on the number of FFDHE groups we
might ever name, but i don't think a limit of 32 FFDHE groups (as in the
proposed range above) is particularly troubling.  I expect we want
fewer, stronger groups, not more.

Any thoughts or preferences?

        --dkg

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQJ8BAEBCgBmBQJUToz8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcNIQQAND6cpL5EV/NW6V11OvW2p+N
qzZM6Xp0Dd3zu7H4b79X5q/m+814T2GMywVZnKA9Q/TOl1BA/5oyuUqof/UlXZ7V
ifxSCQF8WiA024F9uI+y9c6e21kckNbP2LQiF41jjE2kWzmhxgIHGNjjvUn/rMkI
3Nm+gFlJw1I7D/0sT0O9EkyjKBCuPCmuHBTOocw8usTtuYXZ2lN9w65QVs7Imp+w
2XFE4Gg3HRx8GbEoDQIW1H7mhgtksQrAQ7v38DfMmfD4IopNo9vhNAVV7o4hk6TS
mjCWuLcN3kZgkioE6ydt0Gbwy+FBvTyMzwHLJ4TpNhns1sf2139eu1Zpy21XWcGi
QvtlbagSQIEzEbxi9X4K8ZZa5ccwvkdihoBJJpYw/pFumMSbsa2zH9mQn99kJleq
YJ/dYdOPcCVLJb9tVks4oMenJY2VyCJ+xLNwBjHHJYTmf/6s3Fqt79hqBbqa8xdy
M5PBwTy9NsYtjKlYvOa06/fNmIBVp0+rWCVn5GO35x2CyRYi33O1Ps7rZ5yxgOCX
ajqYBiWGEcaiMiuwXaNU9D+9lB2HQajIMSfz4itX1LTErFkgk+uNMK3zM5fOMzl+
sGJPusUp8qTcmTfA5j4YO7D/txgX1cYw3LtZ42Dee6lBA4E0FQ2xLS6g6e3t2snz
QOBR3cudVN/d0j6k0o1q
=MBQH
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Oct 27 11:32:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594501ACEAB for ; Mon, 27 Oct 2014 11:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtl62k325qQX for ; Mon, 27 Oct 2014 11:32:04 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D161A8AA3 for ; Mon, 27 Oct 2014 11:30:01 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1DA162AB24B; Mon, 27 Oct 2014 18:30:00 +0000 (UTC)
Date: Mon, 27 Oct 2014 18:30:00 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141027182959.GJ19158@mournblade.imrryr.org>
References: <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com> <544C1BC3.5060204@streamsec.se> <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com> <544E0682.30804@streamsec.se> <1414405551.2543.8.camel@dhcp-2-127.brq.redhat.com> <544E254A.3020501@streamsec.se> <1414408020.2543.13.camel@dhcp-2-127.brq.redhat.com> <544E2E5D.4000805@streamsec.se> <874mupwf0k.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <874mupwf0k.fsf@alice.fifthhorseman.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4gQ1yq11eM1P92DcoPnSmabUKMU
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 18:32:10 -0000

On Mon, Oct 27, 2014 at 02:20:43PM -0400, Daniel Kahn Gillmor wrote:

> I see three ways to achieve this goal:
> 
>  0) reintroduce an explicit (contentless) ClientHello extension that
>     means "i understand FFDHE named groups"
> 
>  1) allocate a single codepoint in the named groups registry that means
>     "i understand FFDHE named groups" but is not a negotiable group
> 
>  2) carve out a range of codepoints in the named groups registry that
>     will be used only for FFDHE named groups (and no other codepoints in
>     that registry will have FFDHE).  This way, servers can recognize a
>     named FFDHE group, even if they don't know what it is.

For completeness:

   3)  Like 0), but not contentless.  The extension lists the
       supported FFDHE groups.  The existing supported curves
       extension continues to only signal elliptic curves.

[ Perhaps I missed the discussion where this was already suggested and
  ruled out.  Sorry about that... ]

-- 
	Viktor.


From nobody Mon Oct 27 11:58:43 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B3D1A802B for ; Mon, 27 Oct 2014 11:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnS3CGqg71Lw for ; Mon, 27 Oct 2014 11:58:21 -0700 (PDT)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 309201AC41F for ; Mon, 27 Oct 2014 11:58:21 -0700 (PDT)
Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-01v.sys.comcast.net with comcast id 8JxL1p00G2Fh1PH01JyL5o; Mon, 27 Oct 2014 18:58:20 +0000
Received: from [IPv6:::1] ([71.202.164.227]) by resomta-ch2-08v.sys.comcast.net with comcast id 8JyK1p00B4uhcbK01JyK0A; Mon, 27 Oct 2014 18:58:20 +0000
Message-ID: <544E95CB.4090507@brainhub.org>
Date: Mon, 27 Oct 2014 11:58:19 -0700
From: Andrey Jivsov 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5449E969.9000800@brainhub.org>  <544AB4B4.2010305@brainhub.org>  <544B5764.9020006@brainhub.org>  <544B5D82.2080900@brainhub.org>  <544BFCED.9080904@brainhub.org>  <544C6C00.3070903@brainhub.org> <87a94hwna5.fsf@alice.fifthhorseman.net>
In-Reply-To: <87a94hwna5.fsf@alice.fifthhorseman.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414436300; bh=PIp4s6/Obpg3h/VKLa+W2sKvEN1rMkAvH2Jc24TIEdc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fbmMg6Tld5nj/wYipdWTdOphVIn35CJWXFrr77TeVmUbdGQDspHSVXhKkGgfjEoN1 YmExtm7VxAtbuX2oXs4FB98KEXnvpIk/QNSDBU8Uq4kRHEcq6T6cVpGTIJH+HJ2mUB 20EFPvlQrs9J68M81D+93kR+cxwzmgTuiNhGxuwsUn8FXLdhAypVL09WLoaigaDOLx FIU/YUN9sMRhFicq8CGwhczFE5wnhQz4OLaw+oLve7zfNKQ+qp+zqJdjtztBZj2Eiz Nx9F8WSg//9TWMFqFCSd45Bb2dLlt5wE6CcPgSeZnGNIj8i4/jT/g5DQ16CmXZKPK/ v/9zKgkoi+Hkw==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/44rjJ33t3OIGU5ollnYX0JF0pI4
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 18:58:25 -0000

On 10/27/2014 08:22 AM, Daniel Kahn Gillmor wrote:
> On Sat 2014-10-25 23:35:28 -0400, Andrey Jivsov wrote:
>> Let's wait with TLS_FALLBACK_SCSV for a minute :-).
>>
>> To be even more specific, let's simplify the above a bit:
>>
>>          TLS1.2: X, Y
>>          TLS1.1: X
>>          TLS1.0: X
>>          SSL3.0: RC4-MD5
>>
>> ( SSL3.0 has only RC4-MD5, and RC4-MD5 is not in X or Y. )
>   [...]
>> Example, using the above table:
>>
>> ClientHello: TLS1.1+RC4-MD5+TLS_FALLBACK_SCSV
>> Server: MUST fail
>>
>> v.s.
>>
>> ClientHello: TLS1.1+RC4-MD5
>> Server: negotiates SSL3.0+RC4-MD5
>
> I think you've just demonstrated that the server is misconfigured in
> this example.
>
> Because of its misconfiguration, the server has selected SSL3.0 when it
> could have selected TLS1.1.
>

... or it's a feature on the server to kill SSL3.0-era cipher when 
SSL3.0 is disabled in a browser

> (this scenario might have more nuance if we're talking about a TLS 1.3
> specification that doesn't permit negotiation of RC4-MD5, but that's not
> the scenario painted above)


>
> ----
>
> In general, i don't have a lot of sympathy for the complaint that a
> network failure causes fallback negotiation, which might fail.  Outside
> of TLS, when a network failure causes a TCP session to abort, the
> connection fails anyway.
>
> We should have guidance to the implementer of any fallback dance that
> the receipt of an inappropriate_fallback alert means you should clear
> your notion of whether a given host needs a fallback.
>
> In a browser context, this means that the user clicks "reload", and they
> get a new try at the connection.  This is something users are familiar
> with in other network-glitch scenarios.
>

I think that these fallback heuristics will contain false-positives. My 
thought was that if the server has SHOULD fail, it could do something 
like never fail on TLS1.1 and higher (or TLS1.2 when TLS1.3 is out). 
Otherwise one must accept that servers implementing TLS_FALLBACK_SCSV 
will contribute to higher number of failed handshakes.

>       --dkg
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From nobody Mon Oct 27 12:18:02 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10951A8A06 for ; Mon, 27 Oct 2014 12:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWugIFSsUlF9 for ; Mon, 27 Oct 2014 12:17:28 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D421C1A903F for ; Mon, 27 Oct 2014 12:17:27 -0700 (PDT)
Received: from [10.70.10.51] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id CE9BBF986; Mon, 27 Oct 2014 15:17:25 -0400 (EDT)
Message-ID: <544E9A42.9080503@fifthhorseman.net>
Date: Mon, 27 Oct 2014 15:17:22 -0400
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0
MIME-Version: 1.0
To: Andrey Jivsov , tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5449E969.9000800@brainhub.org>  <544AB4B4.2010305@brainhub.org>  <544B5764.9020006@brainhub.org>  <544B5D82.2080900@brainhub.org>  <544BFCED.9080904@brainhub.org>  <544C6C00.3070903@brainhub.org> <87a94hwna5.fsf@alice.fifthhorseman.net> <544E95CB.4090507@brainhub.org>
In-Reply-To: <544E95CB.4090507@brainhub.org>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Gj2Txtsp21FsJbAxeIs0hXoJss0sTXMKD"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d_of7Ee3TCygt7D4IZk-egFrx9k
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 19:17:35 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Gj2Txtsp21FsJbAxeIs0hXoJss0sTXMKD
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 10/27/2014 02:58 PM, Andrey Jivsov wrote:

> I think that these fallback heuristics will contain false-positives. My=

> thought was that if the server has SHOULD fail, it could do something
> like never fail on TLS1.1 and higher (or TLS1.2 when TLS1.3 is out).
> Otherwise one must accept that servers implementing TLS_FALLBACK_SCSV
> will contribute to higher number of failed handshakes.

The failed handshakes associated with false positive fallback behavior
are from network glitches, right?  not from poorly-implemented or
unmaintained servers.

in the face of a network glitch, user agents have three options (browser
behavior in parens):

 0) report the connection failure up the stack (browsers: show the user
the "try again button")

 1) automatically try the connection again, same as last time

 2) try the connection again with a fallback handshake



in the false positive cases that we're discussing here, (1) is probably
the best option.  doing (2) leads directly to choosing a degraded
ciphersuite.

including the SCSV with (2) gives the client an inappropriate_fallback
alert, which they can use to recognize the false positive situation and
do (1) instead.

	--dkg


--Gj2Txtsp21FsJbAxeIs0hXoJss0sTXMKD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJUTppDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcZDEP/09k8PDYQHILzuNts1M9mYrC
KLS3p1+5dt3D+rKs5V6yop7mKBmuF1Tfuh41AW8UizG771aR4jcrT31QHKCWHgXS
CkvRk2+Tg1Q6I/4YHZmYKown9QNc3qcWMrsbRYg+D9TwzDzPEfMKaIRv1cjKR2C9
ZVM0HhldNauhLJLnjIC43sfXRk+dE8riHdgEBd+hnqJN1kD4L7v8jAkPCvBJNmuU
yUhSLcmFN4cSne0waH543zNYYQxDKQhO70emNDeItcB0NrV3FsLjoaoPNo3LAj1i
fV8ATgiRlib4X1fEYZBTaqkgYg9d1oJT+c1RSfoOnoqzxjq227kBQDPPTy1JlMKJ
68fGdUkAC9ksUd/VNp2fNfiI5Dn0f2sz/p/SEG6cLyLqaJblKDfx/hzy/omjeVoi
m5YFwiMRiGeGaIExgSbHYrsbzm8sGWolhj77gde/Fqr7eI60wACloq67F0KCyST9
rvJaZTUEPOGzCcwsg0JJnP9I1iog5XToAaHUEivT2lUKr3lurq9ghOGzZigFcWGs
k1XZf5lcn7zF9YvZkCG/cvQp+rU5NpOS834Di/W7oFP+ny8XiPk2m1/a4rLhtbgr
nn8bx4XX83L+fp6FH9Bi83LzBLjBPEf+ympJ3XphqPfXkP93PSSTfPWIR/mnBtBf
Lf8P9600dQ04bNNW6NtH
=/bYE
-----END PGP SIGNATURE-----

--Gj2Txtsp21FsJbAxeIs0hXoJss0sTXMKD--


From nobody Mon Oct 27 12:39:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA321AD1EE for ; Mon, 27 Oct 2014 12:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Level: 
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCtkyfhe8rnm for ; Mon, 27 Oct 2014 12:38:40 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152901A00F6 for ; Mon, 27 Oct 2014 12:38:34 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 08F7571BB9; Mon, 27 Oct 2014 20:38:32 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 01AD94405F; Mon, 27 Oct 2014 20:38:31 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id EF06C1AF5A; Mon, 27 Oct 2014 20:38:31 +0100 (CET)
In-Reply-To: 
To: Bodo Moeller 
Date: Mon, 27 Oct 2014 20:38:31 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141027193831.EF06C1AF5A@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tygazZSsyXyau9JfxG2DxQjBPYw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 19:38:46 -0000

Bodo Moeller wrote:
>
> Martin Rex :
>> 
>> Rather than aborthing the TLS handshake, the server ought to include
>> a TLS extension in the ServerHello indicating that he recognized a
>> potentially inappropriate fallback and otherwise continue the TLS handshake
>> in the regular fashion, leaving the decision of whether&how to continue
>> entirely up to those clients who do perform insecure fallbacks.
> 
> That would work too, but the server would then be doing all the work to
> send a ServerKeyExchange even if the client is going to abort the
> connection.

I do believe the server load issue here to be sufficiently close to
marginal to be irrelevant.

Even you write somthing to this effect:

> 
> Well, even just having to fall back to make the connection work indicates
> that something is wrong -- that's not a generally expected way of
> establishing a TLS connection. (Clients can gather some statistics without
> sending TLS_FALLBACK_SCSV if they want to use the connection regardless.)

The problem with having the server (rather than the falling-back client)
abort the connection is that the client has no reliable indicator to
figure out the reason for connection failures,  and have to continue
relying on flawed heuristics.  MSIE has a similar bug in connection
management that FF used to have over several years (and which could often
be observed/reproduced by by hitting  ("reload") quickly several
times on complex pages).  On MSIE, I saw it as a result of complex
pages with Javascript-based navigation that performed (and killed)
background downloading of images.


>
> It seems that the response mechanism that you propose would allow the
> server to confirm to that client that the server noticed that the client
> noticed that something is wrong. What would really be gained by that,
> compared to what the current TLS_FALLBACK_SCSV protocol offers?


It would leave the decision whether to abort or continue the handshake
with the one-and-only connection peer that is (a) doing the fallback
and (b) in the position to establish another connection and attempt
another handshake, and (c) query the user interactively if something
odd is going on.


I would gladly add a server extension into ServerHello of our TLS
implementation in response to a FALLBACK SCSV, whereas I will entirely
ignore this proposal as is.


-Martin


From nobody Mon Oct 27 15:08:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129331A03E1 for ; Mon, 27 Oct 2014 15:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhWrCoTnvp52 for ; Mon, 27 Oct 2014 15:08:12 -0700 (PDT)
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C6B1A03A0 for ; Mon, 27 Oct 2014 15:08:04 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id z12so4110179wgg.21 for ; Mon, 27 Oct 2014 15:08:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IuL43cGpumhYnLLGmsUqZyTw/7E42TRyvEY0Jajc/bo=; b=TvE+dlo8pbd/4zZ+BNnqhTN3ecNGDiZ4G69Q5ak1KuUUgrvMrnLjHiRvoYyl/Zh1Sp l8iVNaV7nUX8TQExu8kPRPm7G+WABOToIwGwHgqxG4rWlWGwNktlB4eFzBwaWr0JWnA/ dE5lM0fCEPwqJSaulAsc8GqYK5/6Ts2eef+lb1asgQt7x2fwpouVP9gkLKGzpe0Ea1Ol /myPsU11+SSS0fGgkowd2B3TfabsJnTYXQasMcfNnqK4LaiuedhUluV2Ym6yDx3Ax7xs ok/ptVTAzKvcObh1iEcgICHxDuCez/fVenhCYIHztqJzwRl1gVDv1s++cLaXfv0D45Dx gDEQ==
X-Gm-Message-State: ALoCoQnUBIgPXQnGJPR1MunrUh//aQhEDzVBB2//s+OHhkiUJSAhonKIlNTws571zv3PWE6pWU13
X-Received: by 10.180.103.233 with SMTP id fz9mr22984363wib.80.1414447682960;  Mon, 27 Oct 2014 15:08:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Mon, 27 Oct 2014 15:07:22 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4F98@USMBX1.msg.corp.akamai.com>
References:   <20141022125359.GA18704@LK-Perkele-VII>  <20141022132623.GA19894@LK-Perkele-VII>  <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4F98@USMBX1.msg.corp.akamai.com>
From: Eric Rescorla 
Date: Mon, 27 Oct 2014 15:07:22 -0700
Message-ID: 
To: "Salz, Rich" 
Content-Type: multipart/alternative; boundary=f46d044280cab2566b05066ec3b7
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dKc9urls54Ct0fbDvHgZWNbIs4U
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 22:08:17 -0000

--f46d044280cab2566b05066ec3b7
Content-Type: text/plain; charset=UTF-8

One way to handle this would be to separate out the things that indicate
cryptographic capabilities from those that indicate proposed identity.

Specifically, CertificateRequest currently contains:

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;


But as is noted in 5246, there is redundancy here:

   The interaction of the certificate_types and
   supported_signature_algorithms fields is somewhat complicated.
   certificate_types has been present in TLS since SSLv3, but was
   somewhat underspecified.  Much of its functionality is superseded by
   supported_signature_algorithms.  The following rules apply:


And since we have removed the non-signing modes in 1.3, arguably we *just*
need signature_algorithms to specify the cryptographic parameters. Further,
I would argue that the certificate_authorities field is an practice a mess
and doesn't belong at the TLS layer (note that we don't have an analog to
it for the client to tell the server which CAs it supports). [0]

I would argue that the natural thing to do is to keep the cryptographic
pieces
in TLS but move them into the extensions (to match what the client sends).
Specifically, in TLS 1.3 do:

1. Modify https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 to let the
server send the SignatureAlgorithms extension in the ServerHello.

2. Allow the server to send the Supported Elliptic Curves extension
https://tools.ietf.org/html/rfc4492#section-5.1.1 in the ServerHello.


This would have a number of advantages:

1. A more symmetric design since you would use the same extensions in
both directions.

2. A more expressive (and yet simpler) cryptographic negotiation design
since we could indicate both algorithms and groups.

3. Push off the clumsy PKI-based part into the application while leaving the
TLS-relevant crypto part in TLS.

4. It's consistent with both server-solicited and unsolicited authentication
because the client knows what kinds of certificate it is allowed to deliver.

If we make this change, we could still leave CertificateRequest in place,
but
it could be empty, just indicating that the server wants some kind of client
auth and let the client decide. We might also allow the client to say that
he is going to provide it and let the server say OK, to match MT's CANT
draft. The point is that this would leave us with an orthogonal design that
detached capabilities from requests.

-Ekr









On Wed, Oct 22, 2014 at 8:59 AM, Salz, Rich  wrote:

> > I tend to think that we need a more general mechanism for indicating
> > support for certificate types and signature algorithms.  Maybe we could
> > unconditionally include those in the early handshake instead.
>
> Yes.  In two years when MSFT and Google start deprecating SHA-2 for
> Keccak, it'd be nice to know which cert chain to send.  Or when I don't
> know whether to send an RSA or ECDSA certificate next year.
>
> --
> Principal Security Engineer, Akamai Technologies
> IM: rsalz@jabber.me Twitter: RichSalz
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f46d044280cab2566b05066ec3b7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


One way to handle this would be to separate out the things=
 that indicate
cryptographic capabilities from those that indicate prop=
osed identity.

Specifically, CertificateRequest cu=
rrently contains:

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;


But as is noted in 5246, there is redundanc=
y here:

   The interaction of the c=
ertificate_types and
   supported_signature_algorithms fields is somewhat complicated.
   certificate_types has been present in TLS since SSLv3, but was
   somewhat underspecified.  Much of its functionality is superseded by
   supported_signature_algorithms.  The following rules apply:
<=
div>

And since we have removed the non-signing modes in =
1.3, arguably we *just*
need signature_algorithms to specify the =
cryptographic parameters. Further,
I would argue that the certifi=
cate_authorities field is an practice a mess
and doesn't belo=
ng at the TLS layer (note that we don't have an analog to
it =
for the client to tell the server which CAs it supports). [0]
I would argue that the natural thing to do is to keep the crypt=
ographic pieces
in TLS but move them into the extensions (to matc=
h what the client sends).
Specifically, in TLS 1.3 do:
=




T=
his would have a number of advantages:

1. A more s=
ymmetric design since you would use the same extensions in
both d=
irections.

2. A more expressive (and yet simpler) =
cryptographic negotiation design
since we could indicate both alg=
orithms and groups.

3. Push off the clumsy PKI-bas=
ed part into the application while leaving the
TLS-relevant crypt=
o part in TLS.

4. It's consistent with both se=
rver-solicited and unsolicited authentication
because the client =
knows what kinds of certificate it is allowed to deliver.

If we make this change, we could still leave CertificateRequest in =
place, but
it could be empty, just indicating that the server wan=
ts some kind of client
auth and let the client decide. We might a=
lso allow the client to say that
he is going to provide it and le=
t the server say OK, to match MT's CANT
draft. The point is t=
hat this would leave us with an orthogonal design that
detached c=
apabilities from requests.

-Ekr









=

On Wed, Oct 22, 2014 at 8:59 AM, Salz, Rich <rsa=
lz@akamai.com> wrote:
> I tend to think that we need a more general mechanism for =
indicating

> support for certificate types and signature algorithms.=C2=A0 Maybe we=
 could

> unconditionally include those in the early handshake instead.



Yes.=C2=A0 In two years when MSFT and Google start deprecating SHA-2=
 for Keccak, it'd be nice to know which cert chain to send.=C2=A0 Or wh=
en I don't know whether to send an RSA or ECDSA certificate next year.<=
br>


--

Principal Security Engineer, Akamai Technologies

IM: rsalz@jabber.me Twitter: RichSal=
z




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--f46d044280cab2566b05066ec3b7--


From nobody Mon Oct 27 15:11:47 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BAA1A04BA for ; Mon, 27 Oct 2014 15:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42YPH38G75BI for ; Mon, 27 Oct 2014 15:11:22 -0700 (PDT)
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D6E1A066C for ; Mon, 27 Oct 2014 15:10:51 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id l18so43478wgh.34 for ; Mon, 27 Oct 2014 15:10:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yLsuiXS5qFl26oj8m7eFfzp3yp8Gj4QEbi9eHprnbHc=; b=XZVorfJ3Hqwu3b1n+8kCwPHA8taMHDdT6intdfgK0uh5HFFF4JWCurigxPbE+gGExK tNQN3AkshfKT348cn6yYEpVVNzfEuPVmg6wmVJ/SYA+/z3rFVC7iRzwlMgdAmsn0uI0E WjuTV9Xj6sEQ2lDgvKRMPcPr0i29/E01/j/2hAJ/p3bWWxGOHgE6A726sREe1bXrCIts lbG68LFCRHu1Lh/zoXf8cxVT41744RpKhJpWvL/SWxUjmyjNe/ZFnVgXmcJK82QDbb8v RwL+kejoQcaNrbRpM+FIlzasOKtsv/xXSt2lZSqmHukrzI++cE22OTYJm35YWfnTMTiw +cpw==
X-Gm-Message-State: ALoCoQmOYhI328nlcRqIeiG/wb4r+CdPxvvge0DSGN5lWettTLikTG1xW8FT2burPFzLytoaaCIq
X-Received: by 10.194.187.77 with SMTP id fq13mr26039222wjc.14.1414447850119;  Mon, 27 Oct 2014 15:10:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Mon, 27 Oct 2014 15:10:10 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz>
From: Eric Rescorla 
Date: Mon, 27 Oct 2014 15:10:10 -0700
Message-ID: 
To: Peter Gutmann 
Content-Type: multipart/alternative; boundary=047d7bb03afaa903f805066ecd97
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6CQNC2HS5gkTPRUDSGxAMqENauI
Cc: "" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 22:11:27 -0000

--047d7bb03afaa903f805066ecd97
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 22, 2014 at 3:01 PM, Peter Gutmann 
wrote:

> Eric Rescorla  writes:
>
> >Given that people seem to think that compressed points are better, I
> figured
> >that was the way to go. If people prefer to just require uncompressed
> points
> >(at least for the existing X9.63 curves) I could certainly live with that.
>
> Uncompressed points have been a MUST in TLS since ECC was introduced, and
> are
> also a MUST everywhere else.  So adding compressed points as a MUST as well
> won't get rid of uncompressed points in any way, it'll just add more
> options
> that need to be supported.


As I said above, I'm principally trying to get rid of negotiation so we
have one
point format for each curve. I could certainly live with requiring
uncompressed
only for the X9.62 curves and then defining a new, cleaner format for the
new CFRG curves.

-Ekr

--047d7bb03afaa903f805066ecd97
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 22, 2014 at 3:01 PM, Peter Gutmann <pgut001@cs.auc=
kland.ac.nz> wrote:
E=
ric Rescorla <ekr@rtfm=
.com> writes:



>Given that people seem to think that compressed points are better, I fi=
gured

>that was the way to go. If people prefer to just require uncompressed p=
oints

>(at least for the existing X9.63 curves) I could certainly live with th=
at.



Uncompressed points have been a MUST in TLS since ECC was introduced=
, and are

also a MUST everywhere else.=C2=A0 So adding compressed points as a MUST as=
 well

won't get rid of uncompressed points in any way, it'll just add mor=
e options

that need to be supported.

As I said above,=
 I'm principally trying to get rid of negotiation so we have one
<=
div>point format for each curve. I could certainly live with requiring unco=
mpressed
only for the X9.62 curves and then defining a new, clean=
er format for the
new CFRG curves.

-Ekr<=
/div>





--047d7bb03afaa903f805066ecd97--


From nobody Mon Oct 27 15:14:26 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347051A040C; Mon, 27 Oct 2014 15:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-ZiNKL2Jg4N; Mon, 27 Oct 2014 15:14:17 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1711A0B76; Mon, 27 Oct 2014 15:14:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.1.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141027221408.23949.47145.idtracker@ietfa.amsl.com>
Date: Mon, 27 Oct 2014 15:14:08 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YyeZ-qyXuxh1-UJ8aSidMOb8BL8
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-tls13-03.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 22:14:19 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : The Transport Layer Security (TLS) Protocol Version 1.3
        Authors         : Tim Dierks
                          Eric Rescorla
	Filename        : draft-ietf-tls-tls13-03.txt
	Pages           : 93
	Date            : 2014-10-27

Abstract:
   This document specifies Version 1.3 of the Transport Layer Security
   (TLS) protocol.  The TLS protocol provides communications security
   over the Internet.  The protocol allows client/server applications to
   communicate in a way that is designed to prevent eavesdropping,
   tampering, or message forgery.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-tls13-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Oct 27 16:05:46 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681881A1B8D for ; Mon, 27 Oct 2014 16:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4AkFk1slEDj for ; Mon, 27 Oct 2014 16:05:36 -0700 (PDT)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0D91A6EF4 for ; Mon, 27 Oct 2014 16:03:50 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id gf13so444402lab.31 for ; Mon, 27 Oct 2014 16:03:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZK2pBefBwbUSJjybDr3xaa3Rs/vXX2l2QTmSLmJZOdo=; b=HefkWqJ56ifWaAQDHluvQXs/pzOrhO7xxH46lJ42q9+tPpU9lqRRKyA5Sdd5pTe+mY wvs3Dnb972U9ui8YFQzHCOnf09fN7QR0qAeC0stKDfdsi22Aw/fEYcNxRvftnNHprSjY q6mkdWPlu77YqWfvrC29axTQr8Z00E/Giz3z6X0RENBVVHGCfL5gA9uSPep2FAtcVdkV sPzf9WWyxwJfG02GttenkTxqNKIFpBMGUXtGMwvg3Mnyw20X641oK9Lhg5cxaSWngEpc BPziyRM1FUHjZdMI/yhNj0UNunNpZCR8h47eBJ3RIJfvf8nr39wBDsb8RzIshFj3kM+P 9y1g==
MIME-Version: 1.0
X-Received: by 10.152.120.199 with SMTP id le7mr26533719lab.67.1414451028669;  Mon, 27 Oct 2014 16:03:48 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Mon, 27 Oct 2014 16:03:48 -0700 (PDT)
In-Reply-To: 
References:   <20141022125359.GA18704@LK-Perkele-VII>  <20141022132623.GA19894@LK-Perkele-VII>  <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4F98@USMBX1.msg.corp.akamai.com> 
Date: Mon, 27 Oct 2014 16:03:48 -0700
Message-ID: 
From: Martin Thomson 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/v70pZ8eR62uQhPGyc9TTsqYGPfk
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 23:05:39 -0000

On 27 October 2014 15:07, Eric Rescorla  wrote:
> If we make this change, we could still leave CertificateRequest in place,
> but
> it could be empty, just indicating that the server wants some kind of client
> auth and let the client decide. We might also allow the client to say that
> he is going to provide it and let the server say OK, to match MT's CANT
> draft. The point is that this would leave us with an orthogonal design that
> detached capabilities from requests.


I think that your proposed change makes a lot of sense.  I think that
what I'd like to see is something very definite: either a certificate
is provided, or not.  If Finished is at all at risk (and I think that
it is), then we'll need a clear demarcation point at the end of the
handshake.

Also, as the discussion on Update highlighted, I think that we want
explicit acknowledgment of any attempt to authenticate.  This is only
really relevant for the client, which needs to be able to know that
the server has received credentials (authorization is, of course, a
decision separate from that).


From nobody Mon Oct 27 16:06:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C7D1A6F0E for ; Mon, 27 Oct 2014 16:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaMUQAx4Vr5T for ; Mon, 27 Oct 2014 16:06:08 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4241A6EDB for ; Mon, 27 Oct 2014 16:04:37 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id gq15so396780lab.35 for ; Mon, 27 Oct 2014 16:04:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vh04u1ssrssRuC7ZxKeCgcmHWYUFekeJbgnOX/VqgHQ=; b=eH/WVnIDBeEe6kpqjJDK/Hy/1FuMBPlpdtx0HG1waXts+9WPNbqd+N9aiJtn7xvRtt si8r/dD5LvExsPfXfOHF+Bc1zOql4a1mhFHCthXkXWRAgpz69peV+aszdGMI9RBmP5UA arFV0i8e9/Vt7+P99Qz03fqnJsmMRmcHE5rSUDpUjEHFTpsnewWP/vDYTNY6FQymR4bs OOd0FWWgEuJxgH8YP48mf68jehRv1TMkImzjVRDgn1+6b8G752bS/b5o5Pb4nm1nZhM5 jID8JsCdYCMLzkHBf8GSNkCmluTdPkUx2AD+RQiZsdZkil3UV0YAZqe1RKAoULVsfC1g SIwA==
MIME-Version: 1.0
X-Received: by 10.152.5.201 with SMTP id u9mr27052697lau.24.1414451075896; Mon, 27 Oct 2014 16:04:35 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Mon, 27 Oct 2014 16:04:35 -0700 (PDT)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz> 
Date: Mon, 27 Oct 2014 16:04:35 -0700
Message-ID: 
From: Martin Thomson 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fL7sxHUO-cRXpuYlCHxgsMOdm7g
Cc: "" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 23:06:20 -0000

On 27 October 2014 15:10, Eric Rescorla  wrote:
> As I said above, I'm principally trying to get rid of negotiation so we have
> one
> point format for each curve. I could certainly live with requiring
> uncompressed
> only for the X9.62 curves and then defining a new, cleaner format for the
> new CFRG curves.

And maybe we could define a new cleaner format for the existing curves too...


From nobody Mon Oct 27 17:55:52 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879631A1B9C for ; Mon, 27 Oct 2014 17:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aCGZ1lMdC8l for ; Mon, 27 Oct 2014 17:55:44 -0700 (PDT)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24281A8700 for ; Mon, 27 Oct 2014 17:55:44 -0700 (PDT)
Received: by mail-yk0-f173.google.com with SMTP id 131so858847ykp.18 for ; Mon, 27 Oct 2014 17:55:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eeJ81gnAxfYDepxDYROrD8no6+5CNighrhMN4qfiHHg=; b=UGore+21tswTLEEM41IG22pyScL8+weDh5j9crrn2sQbMv6GhUOi05xhZLo8qGeMUx hx2RVy47dG+mRzPmogdc/91HHunzJdYD0C4p0lZGYWF3WB2jEAeaWaNGukPwl0BDgzhx zCo9x1li2/mjbQuGgmI5JLECfVsHf92JJXXHRVaaQ7mumtmNTByNEnhZexgssRVqoVpb nlAXO3QnwDJIzhJviFS/qYhP87JnD8ezGMVet3avwo1ynbEODBO7S3Atdpsj9DwWj2d/ sbm3iHlAX+g8d2U9Apr+snXVFkSVM4TLbDfZbtm98frrP2bQvjHDMAGP/F9D/pnctSPV 4anA==
MIME-Version: 1.0
X-Received: by 10.170.111.5 with SMTP id d5mr89158ykb.20.1414457744100; Mon, 27 Oct 2014 17:55:44 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Mon, 27 Oct 2014 17:55:44 -0700 (PDT)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz>  
Date: Mon, 27 Oct 2014 17:55:44 -0700
Message-ID: 
From: Watson Ladd 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/03LAxv6kbgicjcbTbCwxqwDT6zk
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 00:55:46 -0000

On Oct 27, 2014 4:06 PM, "Martin Thomson"  wrote:
>
> On 27 October 2014 15:10, Eric Rescorla  wrote:
> > As I said above, I'm principally trying to get rid of negotiation so we have
> > one
> > point format for each curve. I could certainly live with requiring
> > uncompressed
> > only for the X9.62 curves and then defining a new, cleaner format for the
> > new CFRG curves.
>
> And maybe we could define a new cleaner format for the existing curves too...
>

What's wrong with SEC1?

Sincerely,
Watson Ladd

> _______________________________________________
> TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls


From nobody Mon Oct 27 19:05:51 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717BB1A6EF4 for ; Mon, 27 Oct 2014 19:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.239
X-Spam-Level: 
X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuIFuux7Rnpx for ; Mon, 27 Oct 2014 19:05:44 -0700 (PDT)
Received: from BLU004-OMC3S19.hotmail.com (blu004-omc3s19.hotmail.com [65.55.116.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B958A1A1B60 for ; Mon, 27 Oct 2014 19:05:42 -0700 (PDT)
Received: from BLU177-W49 ([65.55.116.72]) by BLU004-OMC3S19.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Mon, 27 Oct 2014 19:05:41 -0700
X-TMN: [jTgeQXVlYsETf7KLpSGks7llFJCDKBrI]
X-Originating-Email: [yuhongbao_386@hotmail.com]
Message-ID: 
From: Yuhong Bao 
To: "tls@ietf.org" 
Date: Mon, 27 Oct 2014 19:05:41 -0700
Importance: Normal
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Oct 2014 02:05:42.0084 (UTC) FILETIME=[AD4E7040:01CFF253]
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k0D3FuQZLMMafPiSCi8tEfkZUkw
Subject: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 02:05:48 -0000

I hope that a Internet-Draft prohibiting SSL 3.0 will be next. Maybe make a=
n exception for things like browser download sites (it is easy to enable TL=
S 1.0 in IE6 but for these kind of sites it is probably not worth the effor=
t).=0A=
=0A=
Yuhong Bao 		 	   		  =


From nobody Mon Oct 27 19:07:29 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E6B1A1B15 for ; Mon, 27 Oct 2014 19:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOMFTiD26YJD for ; Mon, 27 Oct 2014 19:07:16 -0700 (PDT)
Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 910A01A1B1F for ; Mon, 27 Oct 2014 19:07:15 -0700 (PDT)
Received: by mail-qc0-f181.google.com with SMTP id w7so2304522qcr.26 for ; Mon, 27 Oct 2014 19:07:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=lLI0B85U2rZD0R89mYH5R3Pwqp9Wq0Wru7XWI56pGyc=; b=j7yJj73Jiu7BZw61gpvWme/3LFLXAWIUQXpSeXKwHIMkMRAJjokSf7Iy3bdFo5F6HQ 6Sol8QnTtclv1IbakWCVvgqeQmLa9xg32r74orJYGZnS1xhhcdSOatsItuNwBw838Q4e 9mNfWrn9cf3EgRMJSY9wTYnqy/fr1tplYDxHVdKnTljFUmPfEd/FFFb+HZi47ODpFnbl Lbg3A+8BkBD/lG7QN1yJE01iaJU6gqCkjBWbONXcqrPD34auB4sZwUFVo1NF7n8FFfx7 hikp2fPADJcgdQ98iHDMD7TlaEyFploT/OKA8i2zOCfhSQURm+cCoORkQ/DyEr8iFbTY ZGoA==
X-Gm-Message-State: ALoCoQn2/4+VaxlMWXNUp7NpmsqNhaKV85JHyqwb7A0Cu1uA22DR+I4vh1+Aew089m5ZJuUF9IDW
X-Received: by 10.140.31.139 with SMTP id f11mr490412qgf.30.1414462034503; Mon, 27 Oct 2014 19:07:14 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:e7:4db0:7b95:1f7b:4e12? ([2601:a:2a00:e7:4db0:7b95:1f7b:4e12]) by mx.google.com with ESMTPSA id 94sm171654qgg.33.2014.10.27.19.07.13 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Oct 2014 19:07:14 -0700 (PDT)
Message-ID: <544EFA73.6060206@nthpermutation.com>
Date: Mon, 27 Oct 2014 22:07:47 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060504060605020407080003"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/We3QEZVeEnByomAuVHBgbVFwkeo
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 02:07:22 -0000

This is a multi-part message in MIME format.
--------------060504060605020407080003
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 10/27/2014 6:10 PM, Eric Rescorla wrote:
>
>
> On Wed, Oct 22, 2014 at 3:01 PM, Peter Gutmann 
> > wrote:
>
>     Eric Rescorla > writes:
>
>     >Given that people seem to think that compressed points are
>     better, I figured
>     >that was the way to go. If people prefer to just require
>     uncompressed points
>     >(at least for the existing X9.63 curves) I could certainly live
>     with that.
>
>     Uncompressed points have been a MUST in TLS since ECC was
>     introduced, and are
>     also a MUST everywhere else.  So adding compressed points as a
>     MUST as well
>     won't get rid of uncompressed points in any way, it'll just add
>     more options
>     that need to be supported.
>
>
> As I said above, I'm principally trying to get rid of negotiation so 
> we have one
> point format for each curve. I could certainly live with requiring 
> uncompressed
> only for the X9.62 curves and then defining a new, cleaner format for the
> new CFRG curves.

You've said this before and it's unclear that this is the correct approach.


Curve25519 has one (or maybe two) representation(s)  (public keys are 
basically Bignums - DJB has the representation as fixed length octet 
strings representing the little endian encoding - but that seems to be 
based on his specific implementation - its not required by the math as 
far as I can tell) - it also doesn't have multiple curve types.  
NUMS/Edwards curves have another format (I think still undefined).   
NUMS/Montgomery/X9.62 curves a third (a format byte plus one or two 
fixed length octet strings representing big endian bignums).   The math 
for each of these is different  - the only thing they really share is 
the name "Elliptic Curve".   It's unclear that you gain anything trying 
to shoehorn all of these into the same overlying structure except a 
small amount of compression and a large amount of complexity.

Think of it this way - if you can combine  this to cover all of the 
various curve structures, why stop there?  Why not integrate generic DH 
for key agreement and RSA  and DSA for signatures?

Instead, treat each of the different elliptic cryptomath systems as 
distinct and separate.  Define suites that don't require across the 
board mappings of incompatible data and formats.  Retain the 
pluggability of new systems as units.

We've got legacy X9.62 - let's leave it alone.  All the stuff that's 
already defined (suites, formats, certificates, etc) remains as X9.62 
(and the various RFCs) defined it.    New systems, as they are defined, 
get their own code points,suites, public key formats, key agreement 
protocols, signature methods and extensions (if necessary) appropriate 
only for them.

On the point above, uncompressed X9.62 public keys are not going away 
anytime soon and are MUSTs in all the existing standards. Making them 
MUST NOT's in TLS1.3 seems to be a bad idea. If we want to require 
support for compressed points in addition as the next step then *maybe* 
that's the right answer.  But then we probably need to go back to X9.62 
and get them to make that recommendation as well.

Later, Mike









--------------060504060605020407080003
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/27/2014 6:10 PM, Eric Rescorla
      wrote:

    

    

      


        


          
On Wed, Oct 22, 2014 at 3:01 PM,
            Peter Gutmann <pgut001@cs.auckland.ac.nz>
            wrote:

            
Eric
                Rescorla <ekr@rtfm.com>
                writes:

                

                >Given that people seem to think that compressed
                points are better, I figured

                >that was the way to go. If people prefer to just
                require uncompressed points

                >(at least for the existing X9.63 curves) I could
                certainly live with that.

                

              Uncompressed points have been a MUST in TLS since
              ECC was introduced, and are

              also a MUST everywhere else.  So adding compressed points
              as a MUST as well

              won't get rid of uncompressed points in any way, it'll
              just add more options

              that need to be supported.

            


            

            
As I said above, I'm principally trying to get rid of
              negotiation so we have one

            
point format for each curve. I could certainly live
              with requiring uncompressed

            
only for the X9.62 curves and then defining a new,
              cleaner format for the

            
new CFRG curves.

          

        

      

    

    

    You've said this before and it's unclear that this is the correct
    approach.

    

    

    Curve25519 has one (or maybe two) representation(s)  (public keys
    are basically Bignums - DJB has the representation as fixed length
    octet strings representing the little endian encoding - but that
    seems to be based on his specific implementation - its not required
    by the math as far as I can tell) - it also doesn't have multiple
    curve types.  NUMS/Edwards curves have another format (I think still
    undefined).   NUMS/Montgomery/X9.62 curves a third (a format byte
    plus one or two fixed length octet strings representing big endian
    bignums).   The math for each of these is different  - the only
    thing they really share is the name "Elliptic Curve".   It's unclear
    that you gain anything trying to shoehorn all of these into the same
    overlying structure except a small amount of compression and a large
    amount of complexity.

    

    Think of it this way - if you can combine  this to cover all of the
    various curve structures, why stop there?  Why not integrate generic
    DH for key agreement and RSA  and DSA for signatures? 

    

    Instead, treat each of the different elliptic cryptomath systems as
    distinct and separate.  Define suites that don't require across the
    board mappings of incompatible data and formats.  Retain the
    pluggability of new systems as units.

    

    We've got legacy X9.62 - let's leave it alone.  All the stuff that's
    already defined (suites, formats, certificates, etc) remains as
    X9.62 (and the various RFCs) defined it.    New systems, as they are
    defined, get their own code points,suites, public key formats, key
    agreement protocols, signature methods and extensions (if necessary)
    appropriate only for them.

    

    On the point above, uncompressed X9.62 public keys are not going
    away anytime soon and are MUSTs in all the existing standards. 
    Making them MUST NOT's in TLS1.3 seems to be a bad idea. If we want
    to require support for compressed points in addition as the next
    step then *maybe* that's the right answer.  But then we probably
    need to go back to X9.62 and get them to make that recommendation as
    well.

    

    Later, Mike

    

    

    

    

    

    

    

    

  


--------------060504060605020407080003--


From nobody Mon Oct 27 19:43:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D011A1B74 for ; Mon, 27 Oct 2014 19:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6vdDpLmhxHA for ; Mon, 27 Oct 2014 19:43:14 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781651A1B60 for ; Mon, 27 Oct 2014 19:43:14 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id ge10so1692286lab.8 for ; Mon, 27 Oct 2014 19:43:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KeyZz7FbhV8hS5NPD39fq3J94v+Rk31b5pBC8m7TxoQ=; b=g1im7MVsf4X3VAgH4G93BrrkHJYn4ZwaRCsekY3mNxz2U5yTt6kLbi7d/OL4qqPsOs uKtpEvO9/ITTaxa1llKCZkh+v/XDJtGmxiSzukWbMKks/+rmOeg1fa4haBRBUlwwuhGo sf4WP6vnmK61JYmMgpbRlRsDDFqgYgGZpJYQGrrJeE+mGgiF79LptGn6f7rwsFKws0Co Xf/5EgI3Z4yoVgATXaLcAqCK72tJzqdKpFU1Xmv/rk8xVsug6BOQj10rpHtDFV9LUnCc KoCGvUKLhtmdXw2DxAq8j1TtHuCZs7DTXRrp/gr6mKvo1afA/4/ZGS7BkSUB6+TvNLYi QIaQ==
MIME-Version: 1.0
X-Received: by 10.152.116.68 with SMTP id ju4mr390508lab.13.1414464192735; Mon, 27 Oct 2014 19:43:12 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Mon, 27 Oct 2014 19:43:12 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 27 Oct 2014 19:43:12 -0700
Message-ID: 
From: Martin Thomson 
To: Yuhong Bao 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/94z0lAdpkHWgR8jIlH2X1XGmHlM
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 02:43:16 -0000

On 27 October 2014 19:05, Yuhong Bao  wrote:
> I hope that a Internet-Draft prohibiting SSL 3.0 will be next. Maybe make an exception for things like browser download sites (it is easy to enable TLS 1.0 in IE6 but for these kind of sites it is probably not worth the effort).


It didn't meet the deadline, but Richard and I put something together.

https://unicorn-wg.github.io/sslv3-diediedie/

But then we learned that there might be another draft.  That other
draft is probably better.  Not sure if this one is worth doing or not.


From nobody Mon Oct 27 21:27:34 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4C11A0377 for ; Mon, 27 Oct 2014 21:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dsy-ZrMc8QuU for ; Mon, 27 Oct 2014 21:27:28 -0700 (PDT)
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4FE71A0364 for ; Mon, 27 Oct 2014 21:27:27 -0700 (PDT)
Received: by mail-qa0-f50.google.com with SMTP id cs9so4786461qab.23 for ; Mon, 27 Oct 2014 21:27:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jPacNwar1CiXhr6fPkPG44GXD4UL2ZgJu8ruElIx1yM=; b=ALdCDQnDDk7821nrwn3C+zCpA2hp5yisrNm/suR5BPiaJbztvXRu7K1l4Y/WFARoiX wqK4RksjioVz6MRf5dzV8+9kNbLgxdjXarDzwIYdF3C3OH0aAnS0JBMzRqRfKDtx+xis o2a3QOfpN59Jtz8P4dlVM1AquupywMeDJlvybeU5xN9LwDXmxd3AZ4fZF+6aG0Glh/6d jvw8kW5tv0Hy4KRXZTNkjMQ16CixHXlZ+5E8B+gee55J1Aswy1g3VrJJdLdRzSfPftat WbCn7mO9Y1zKFEMfcygm4rrQMKxQD9Q+A4Wgneh4zFPJQP9oqnLNpfsEWV/JnzgGrz4S bR/A==
X-Gm-Message-State: ALoCoQmYnK2ejIuzmrec5AGYdveDybpwxjcBKdOwz4p/FPNfhNoMCqUsDItCTBBbQKJz0NctU3/J
MIME-Version: 1.0
X-Received: by 10.140.104.114 with SMTP id z105mr960359qge.75.1414470446545; Mon, 27 Oct 2014 21:27:26 -0700 (PDT)
Received: by 10.96.155.202 with HTTP; Mon, 27 Oct 2014 21:27:26 -0700 (PDT)
X-Originating-IP: [67.168.161.122]
In-Reply-To: 
References:   <20141022125359.GA18704@LK-Perkele-VII>  <20141022132623.GA19894@LK-Perkele-VII>  <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4F98@USMBX1.msg.corp.akamai.com> 
Date: Mon, 27 Oct 2014 21:27:26 -0700
Message-ID: 
From: Joseph Salowey 
To: Eric Rescorla 
Content-Type: multipart/alternative; boundary=001a1134f4b683b9d6050674100b
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3MFPVPdejFx322DbyRwRayYST8E
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 04:27:31 -0000

--001a1134f4b683b9d6050674100b
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 27, 2014 at 3:07 PM, Eric Rescorla  wrote:

> One way to handle this would be to separate out the things that indicate
> cryptographic capabilities from those that indicate proposed identity.
>
> Specifically, CertificateRequest currently contains:
>
>       struct {
>           ClientCertificateType certificate_types<1..2^8-1>;
>           SignatureAndHashAlgorithm
>             supported_signature_algorithms<2^16-1>;
>           DistinguishedName certificate_authorities<0..2^16-1>;
>       } CertificateRequest;
>
>
> But as is noted in 5246, there is redundancy here:
>
>    The interaction of the certificate_types and
>    supported_signature_algorithms fields is somewhat complicated.
>    certificate_types has been present in TLS since SSLv3, but was
>    somewhat underspecified.  Much of its functionality is superseded by
>    supported_signature_algorithms.  The following rules apply:
>
>
> And since we have removed the non-signing modes in 1.3, arguably we *just*
> need signature_algorithms to specify the cryptographic parameters. Further,
> I would argue that the certificate_authorities field is an practice a mess
> and doesn't belong at the TLS layer (note that we don't have an analog to
> it for the client to tell the server which CAs it supports). [0]
>
>
[Joe]  While I'm not a huge fan of the certificate authorities list, I'm
not sure that punting this to the application layer is the right thing to
do.  Some uses of TLS do not have a way to signal this in a higher layer.
For example, there are some EAP-TLS clients that will choose what
certificate to use based on this information from the server.   It may be
possible to extend EAP-TLS to send a client identity hint or similar
information in the first message from the server, but there really isn't
space in EAP-TLS for non-tls data.   An alternate approach would be the
client makes a guess as to which cert to use and if it isn't right then the
server sends a message encoded in TLS that tells the client what to do.
I'm not overly excited about wither of these approaches since they will
require changes to the applications.




> I would argue that the natural thing to do is to keep the cryptographic
> pieces
> in TLS but move them into the extensions (to match what the client sends).
> Specifically, in TLS 1.3 do:
>
> 1. Modify https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 to let the
> server send the SignatureAlgorithms extension in the ServerHello.
>
> 2. Allow the server to send the Supported Elliptic Curves extension
> https://tools.ietf.org/html/rfc4492#section-5.1.1 in the ServerHello.
>
>
> This would have a number of advantages:
>
> 1. A more symmetric design since you would use the same extensions in
> both directions.
>
> 2. A more expressive (and yet simpler) cryptographic negotiation design
> since we could indicate both algorithms and groups.
>
> 3. Push off the clumsy PKI-based part into the application while leaving
> the
> TLS-relevant crypto part in TLS.
>
> 4. It's consistent with both server-solicited and unsolicited
> authentication
> because the client knows what kinds of certificate it is allowed to
> deliver.
>
> If we make this change, we could still leave CertificateRequest in place,
> but
> it could be empty, just indicating that the server wants some kind of
> client
> auth and let the client decide. We might also allow the client to say that
> he is going to provide it and let the server say OK, to match MT's CANT
> draft. The point is that this would leave us with an orthogonal design that
> detached capabilities from requests.
>
>
[Joe]  I'm not convinced about pushing the PKI part to the application yet,
but I like the rest of the concept.


> -Ekr
>
>
>
>
>
>
>
>
>
> On Wed, Oct 22, 2014 at 8:59 AM, Salz, Rich  wrote:
>
>> > I tend to think that we need a more general mechanism for indicating
>> > support for certificate types and signature algorithms.  Maybe we could
>> > unconditionally include those in the early handshake instead.
>>
>> Yes.  In two years when MSFT and Google start deprecating SHA-2 for
>> Keccak, it'd be nice to know which cert chain to send.  Or when I don't
>> know whether to send an RSA or ECDSA certificate next year.
>>
>> --
>> Principal Security Engineer, Akamai Technologies
>> IM: rsalz@jabber.me Twitter: RichSalz
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a1134f4b683b9d6050674100b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Oct 27, 2014 at 3:07 PM, Eric Rescorla <ekr@rtfm.com>=
 wrote:
One way to handl=
e this would be to separate out the things that indicate
cryptographic =
capabilities from those that indicate proposed identity.

Specifically, CertificateRequest currently contains:

<=
/div>
      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;


But as is noted in 5246, there is redundanc=
y here:

   The interaction of the certificate_=
types and
   supported_signature_algorithms fields is somewhat complicated.
   certificate_types has been present in TLS since SSLv3, but was
   somewhat underspecified.  Much of its functionality is superseded by
   supported_signature_algorithms.  The following rules apply:
<=
div>

And since we have removed the non-signing modes in =
1.3, arguably we *just*
need signature_algorithms to specify the =
cryptographic parameters. Further,
I would argue that the certifi=
cate_authorities field is an practice a mess
and doesn't belo=
ng at the TLS layer (note that we don't have an analog to
it =
for the client to tell the server which CAs it supports). [0]

[Joe] =C2=A0While I'=
;m not a huge fan of the certificate authorities list, I'm not sure tha=
t punting this to the application layer is the right thing to do.=C2=A0 Som=
e uses of TLS do not have a way to signal this in a higher layer.=C2=A0 For=
 example, there are some EAP-TLS clients that will choose what certificate =
to use based on this information from the server. =C2=A0 It may be possible=
 to extend EAP-TLS to send a client identity hint or similar information in=
 the first message from the server, but there really isn't space in EAP=
-TLS for non-tls data. =C2=A0 An alternate approach would be the client mak=
es a guess as to which cert to use and if it isn't right then the serve=
r sends a message encoded in TLS that tells the client what to do. =C2=A0 I=
'm not overly excited about wither of these approaches since they will =
require changes to the applications. =C2=A0


=C2=A0
<=
div>
I would argue that the natural thing to do is to keep the cr=
yptographic pieces
in TLS but move them into the extensions (to m=
atch what the client sends).
Specifically, in TLS 1.3 do:

server send the SignatureAlgo=
rithms extension in the ServerHello.

2. Allow the =
server to send the Supported Elliptic Curves extension
https=
://tools.ietf.org/html/rfc4492#section-5.1.1 in the ServerHello.


This would have a number of advantage=
s:

1. A more symmetric design since you would use =
the same extensions in
both directions.

=
2. A more expressive (and yet simpler) cryptographic negotiation design
since we could indicate both algorithms and groups.

3. Push off the clumsy PKI-based part into the application while l=
eaving the
TLS-relevant crypto part in TLS.

<=
div>4. It's consistent with both server-solicited and unsolicited authe=
ntication
because the client knows what kinds of certificate it i=
s allowed to deliver.

If we make this change, we c=
ould still leave CertificateRequest in place, but
it could be emp=
ty, just indicating that the server wants some kind of client
aut=
h and let the client decide. We might also allow the client to say that
he is going to provide it and let the server say OK, to match MT'=
;s CANT
draft. The point is that this would leave us with an orth=
ogonal design that
detached capabilities from requests.


[Joe] =C2=A0I'm=
 not convinced about pushing the PKI part to the application yet, but I lik=
e the rest of the concept.=C2=A0
=C2=A0
-Ekr

<=
div>




<=
div>


On Wed, O=
ct 22, 2014 at 8:59 AM, Salz, Rich <rsalz@akamai.com> wrote:<=
br>
> I tend to think that we need a=
 more general mechanism for indicating

> support for certificate types and signature algorithms.=C2=A0 Maybe we=
 could

> unconditionally include those in the early handshake instead.



Yes.=C2=A0 In two years when MSFT and Google start deprecating SHA-2=
 for Keccak, it'd be nice to know which cert chain to send.=C2=A0 Or wh=
en I don't know whether to send an RSA or ECDSA certificate next year.<=
br>


--

Principal Security Engineer, Akamai Technologies

IM: rsalz@jabber.me Twitter: RichSalz






_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--001a1134f4b683b9d6050674100b--


From nobody Mon Oct 27 21:40:23 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C669E1A0377 for ; Mon, 27 Oct 2014 21:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae-MQRLt9ZYW for ; Mon, 27 Oct 2014 21:40:21 -0700 (PDT)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C681A03AB for ; Mon, 27 Oct 2014 21:40:20 -0700 (PDT)
Received: by mail-la0-f41.google.com with SMTP id pn19so7111875lab.28 for ; Mon, 27 Oct 2014 21:40:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zl3P+aC35HYjfZHPn4XbLRWrBALw0NPJtXc92PiRqBE=; b=wLpmEgjN/1L10Jd6RgcGNAyCiEWJZysqhkE4xpMecFeOb/kIIL0zM9LwtsCDk/IHjF KZ2OgYHGULlioejrsrc66rxAKs+PpxfLRv+tQM6Z2ZAHZAWM2HoYxBLZz6xdwIyoIqV0 ZsQA7eZGvmh5Yok5P3oqLVIpT/x4Bb+sYqim6BXA7aEDqAsl3qoY3sN3HmlV4CkOdQq1 eJ3a/HQVXMWszMR61l09UruXG1g/sxbcA5pWQzgEmvfT2GTFfpZpofboeuLh7GE0US8r bbeUafrC0bgfRU7ID8rWZLM/xH3p6dy1UKZD1EVf646ovTLhZZmtGsQAu9WYrt38o9Mb n2Kw==
MIME-Version: 1.0
X-Received: by 10.152.116.68 with SMTP id ju4mr846163lab.13.1414471219110; Mon, 27 Oct 2014 21:40:19 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Mon, 27 Oct 2014 21:40:19 -0700 (PDT)
In-Reply-To: 
References:   <20141022125359.GA18704@LK-Perkele-VII>  <20141022132623.GA19894@LK-Perkele-VII>  <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4F98@USMBX1.msg.corp.akamai.com>  
Date: Mon, 27 Oct 2014 21:40:19 -0700
Message-ID: 
From: Martin Thomson 
To: Joseph Salowey 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aatHlIIvh42hxgAFOI-1HYoOuNE
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 04:40:22 -0000

On 27 October 2014 21:27, Joseph Salowey  wrote:
> While I'm not a huge fan of the certificate authorities list, I'm not sure
> that punting this to the application layer is the right thing to do.

Would you be interested perhaps in an optional TLS extension that
allows both client and server to express something about what they are
willing to consider as being authoritative?


From nobody Mon Oct 27 21:48:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9A51A0377 for ; Mon, 27 Oct 2014 21:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IawUROmlwYCv for ; Mon, 27 Oct 2014 21:48:00 -0700 (PDT)
Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D741A0469 for ; Mon, 27 Oct 2014 21:47:59 -0700 (PDT)
Received: by mail-qa0-f45.google.com with SMTP id dc16so4881978qab.18 for ; Mon, 27 Oct 2014 21:47:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=fSGmKku5JS42JREItcL1z0DaqjQ+9Z1EUH28oO7l3QE=; b=QV6Z2guxQhp6T9pbNmPxDsBts7+xGKyNxecVRoV2AlIMJTA0hmA9B7rh10wxwNQVfe yIO0TsB205RQk9IkPOpFu+70fl9e9bbMoi3q4dSMCeJGZ6c+zKEnMP1x/bR51upKnpzX 6ISaz+jtwVI/pdxo5+/5ewrr85FvcBX1DVf+UJ/nb9p5hVAmRchUEv+UYZ3fo2LHO9oH xY8buWEvt7QD++dNoKtPil0K5H77M1exU4Pz2RmBez+IiHCFRuh1cgKV0DCfH1a0DrKS 2t/24Gt031UvNb3SNdnT2If9oKGDdz5z15gXEx+7TELi1R3QRAFI/YYO5YtyXW7lIILP au3w==
X-Gm-Message-State: ALoCoQkFOl7pXlHtzepgFir9zbhc44z+B3oIikFX3coJmyQc9XjMd11IHi4hrYtkyZtnvykRxf6Z
MIME-Version: 1.0
X-Received: by 10.140.106.138 with SMTP id e10mr1102304qgf.71.1414471679084; Mon, 27 Oct 2014 21:47:59 -0700 (PDT)
Received: by 10.96.155.202 with HTTP; Mon, 27 Oct 2014 21:47:59 -0700 (PDT)
X-Originating-IP: [67.168.161.122]
In-Reply-To: 
References: 
Date: Mon, 27 Oct 2014 21:47:59 -0700
Message-ID: 
From: Joseph Salowey 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113a6290fa2cd605067459b4
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qxizIsYeI2X_b_MZ3zopMzwTN9s
Subject: Re: [TLS] November Interim and IETF 91 Meeting details
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 04:48:07 -0000

--001a113a6290fa2cd605067459b4
Content-Type: text/plain; charset=UTF-8

Correction we have the Kahili room on Sunday until 15:30.



On Sun, Oct 26, 2014 at 7:40 PM, Joseph Salowey  wrote:

> Below are the details for the upcoming meetings along with a very drafty
> agenda:
>
> TLS November 2014 Interim Meeting
>
> November 9, 2014, 9:30 - 13:30 -  Kahili room
>
> --------------------------------------------------------------------
>
> Agenda (Draft)
>
> ---------------------
>
> Focus on TLS 1.3 topics (draft-ietf-tls-tls13
> )
>
>    1.
>
>    1.3 Session Resumption
>    2.
>
>    1.3 Key Refresh/Client auth
>    3.
>
>    1.3 (0-RTT)
>
>
>
> IETF 91 TLS Meeting
>
> November 13, 2014, 9 - 11:30 - Coral 5
>
> ------------------------------
>
> Agenda (Draft)
>
> --------------------
>
>    1.
>
>    RC4 (if necessary)
>
> draft-ietf-tls-prohibiting-rc4
> 
>
>    1.
>
>    Downgrade SCSV
>
> draft-ietf-tls-downgrade-scsv
> 
>
>    1.
>
>    Session Hash
>
> draft-ietf-tls-session-hash
> 
>
>    1.
>
>    Finite Field DHE negotiation
>
> draft-ietf-tls-negotiated-ff-dhe
> 
>
>    1.
>
>    TLS 1.3 Topics continued/Recap
>
> draft-ietf-tls-tls13 
>
>

--001a113a6290fa2cd605067459b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Correction we have the Kahili room on Sunday until 15:30.<=
div>


On Sun, Oct 26, 2014 at 7:40 PM, Joseph Salowey <joe@salowey.net=
> wrote:
B=
elow are the details for the upcoming meetings along with a very drafty age=
nda:

TLS November 2014 Interim Meeting
November 9, 2014, 9:3=
0 - 13:30 - =C2=A0Kahili room
-----------------------------------------------------------------=
---

Agenda (Draft) 
---------------------
Focus on TLS 1.3=
 topics (draft-ietf-=
tls-tls13)
  1. 1.3 Session Resumption
    <=
/li>
  2. 1.3 Key Refresh/Client auth
  3. 1.3 (0-RTT)


IETF 91 TLS Meeting 
November 13, 201=
4, 9 - 11:30 - Coral 5
------------------------------

Agenda (Draft)
-=
-------------------
  1. RC4 (if necessary)
draft-ietf-tls-prohibiting-rc4
  1. Downgrade SCSV<=
/span>
draft-ietf-tls-downgrade-sc=
sv
  1. Session Hash
	draft-ietf-tls-session-hash
  1. Fin=
ite Field DHE negotiation
draft-ietf-tls-negotiated-ff-dhe
  1. TLS 1.3 Topics continued=
/Recap
draft-ietf-tls-tls13






--001a113a6290fa2cd605067459b4--


From nobody Mon Oct 27 21:52:42 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF701A03B3 for ; Mon, 27 Oct 2014 21:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbKm3qENJQBC for ; Mon, 27 Oct 2014 21:52:40 -0700 (PDT)
Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205511A1B80 for ; Mon, 27 Oct 2014 21:52:40 -0700 (PDT)
Received: by mail-qg0-f50.google.com with SMTP id a108so2440248qge.37 for ; Mon, 27 Oct 2014 21:52:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=L1aTa8v0f4xJbtlRcKwSwzgMd/qHbkKG8XuvGbuWjSY=; b=iSY2YQCAYEMC43JQGdgJJm6pkAbgM4FX47e1BQQq5eOm7BlmV1eniRCI8ijxOhzT9L 9H55tsXfY0gmotWc/AvFiig3h+PKnpOqPI2zmcyLyem3uSaE6RySVmVqWxlQMHIpjs8T rfCMUumy7ZcnAedi84NNGXqRxTHm7vi5kzgt/OrK3WKqPDqUh/S2QE2XyRwtReopf+Qn nRTKxa1P+52gr4FST1Jo8+OTPFa6bcz0tXvA3Ke5uJzILY6601peGNH21eazogbdK/QM OgfaRby/vu/utJRM9LTa4Cky7DgHZdHul6mBNtSHhNcZB53AKmP3qbP3VcJucBHDRirx zCdw==
X-Gm-Message-State: ALoCoQkqGco0HhOAc4+90b+9rqDAhUqKatoP4EU/l6/LV8iTx1wcRiLr9NBnNCcs6a+x995oJoDR
MIME-Version: 1.0
X-Received: by 10.224.79.79 with SMTP id o15mr1110090qak.93.1414471959342; Mon, 27 Oct 2014 21:52:39 -0700 (PDT)
Received: by 10.96.155.202 with HTTP; Mon, 27 Oct 2014 21:52:39 -0700 (PDT)
X-Originating-IP: [67.168.161.122]
In-Reply-To: 
References:   <20141022125359.GA18704@LK-Perkele-VII>  <20141022132623.GA19894@LK-Perkele-VII>  <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4F98@USMBX1.msg.corp.akamai.com>   
Date: Mon, 27 Oct 2014 21:52:39 -0700
Message-ID: 
From: Joseph Salowey 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=047d7bdc78f8aeaa900506746a51
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kBP6ujM9X9VUyBgkF4u9sLk5sdI
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 04:52:41 -0000

--047d7bdc78f8aeaa900506746a51
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 27, 2014 at 9:40 PM, Martin Thomson 
wrote:

> On 27 October 2014 21:27, Joseph Salowey  wrote:
> > While I'm not a huge fan of the certificate authorities list, I'm not
> sure
> > that punting this to the application layer is the right thing to do.
>
> Would you be interested perhaps in an optional TLS extension that
> allows both client and server to express something about what they are
> willing to consider as being authoritative?
>

[Joe] Yes, I was thinking this would be the way to go, especially if there
was interest in this for multiple protocols.

--047d7bdc78f8aeaa900506746a51
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Oct 27, 2014 at 9:40 PM, Martin Thomson <<=
a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson=
@gmail.com> wrote:
On 27 October 2014 21:27, Joseph Salowey <joe@salowey.net> wrote:

> While I'm not a huge fan of the certificate authorities list, I=
9;m not sure

> that punting this to the application layer is the right thing to do.


Would you be interested perhaps in an optional TLS extension that
allows both client and server to express something about what they are

willing to consider as being authoritative?



[Joe] Yes, I was th=
inking this would be the way to go, especially if there was interest in thi=
s for multiple protocols. =C2=A0


--047d7bdc78f8aeaa900506746a51--


From nobody Mon Oct 27 23:22:33 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8211A00FE for ; Mon, 27 Oct 2014 23:22:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLa6UI0C4koq for ; Mon, 27 Oct 2014 23:22:29 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91FBC1A00FC for ; Mon, 27 Oct 2014 23:22:29 -0700 (PDT)
Received: from [192.168.10.205] ([64.134.223.187]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Mg42v-1XUTbC1aNx-00NTa5 for ; Tue, 28 Oct 2014 07:22:27 +0100
Message-ID: <544F3620.1040402@gmx.net>
Date: Tue, 28 Oct 2014 07:22:24 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3Tj1tC2JIA0t0SVtMSgAe3AgaUJBc13AC"
X-Provags-ID: V03:K0:r9jpIPN/WxmuBPbatwhpO3zCz1CujLyk53wQuV74sQZaP31vhQt 2UbQ4alr6CroEfVT1Vs8besTihkWtGgZ/mvsVy3LgV2EY8VaFw/XKPLV4sjz6WP2YbtLPbW wuxbzJ7owVzdSb5/STGTAA8g65OcJVOmmsY+Nuotf4AeFrkoynpJfWZdX5664UykFRVps9P da3wDcnk4uS5TvF39QYMA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YSODakaf6pROzKcZDHAHCY9vSs8
Subject: [TLS] Updated TLS Cached Info Draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 06:22:31 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--3Tj1tC2JIA0t0SVtMSgAe3AgaUJBc13AC
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

 Hi all,

as a result of the WGLC the cached info draft got a few good review
comments. I have tried to address them with a new document update
(version -17).

Since I missed the draft submission deadline you can find the document
here:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached=
-info/draft-ietf-tls-cached-info-17.txt

I will respond to the review comments directly but here is a short summar=
y:

* Simplified the exchange (as suggested by Ekr).
* Incorporated the optimizations suggested by Ekr regarding the
certificate_authority structure
* Required a collision resistant hash function.
* Clarifications throughout the document.

Ciao
Hannes


--3Tj1tC2JIA0t0SVtMSgAe3AgaUJBc13AC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJUTzYhAAoJEGhJURNOOiAtyh8H/1JxMhRbdQglcCApN4b7/fcy
h+cqZhpZoxafK7PHsUl7rFIHi0kBLc4dUVFRSDybPZ50r8V8f9AMWS+14s8+u61J
hPsc1BNgX5WcfaoBjGwraZAZcVFXl+0BeYVHvVab1P+NmJMVpap434JpG3+EQyuS
/0v0dJYIwbRmkWmSp+wp+DsqzuVtiaqJwxv6DdWJAWDS7QNE1YAjhMnYqiV+fHXE
zQX3fMdepeaKb6hA3GFdnJq+Dtd/n5qXVOM/zm0VxjfDwCel1vXslFScdrcrf6LI
VNi6iO/nNJxAN7zNwusw3IMRZ2KVnYmJLtjoy+kQZSnaMwZ6x7J3J62ZIGMJDzE=
=LufP
-----END PGP SIGNATURE-----

--3Tj1tC2JIA0t0SVtMSgAe3AgaUJBc13AC--


From nobody Tue Oct 28 02:36:07 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBAC1A1A83 for ; Tue, 28 Oct 2014 02:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPviktiJ3KLQ for ; Tue, 28 Oct 2014 02:35:33 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBEB1A1AC5 for ; Tue, 28 Oct 2014 02:35:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=kSIqeui+cNf13matAUDDirSfxHK2d0LKflRdjy+W2hY=;  b=NXHd4NbMjof4QouxvmFpP1ZYzN0Z1O94qhWu96L8yJbFbFcv3qNiGDaJk+oy/L7nBtonorDmysGHqCSg7W/9fnlkNl7IFk2ptGlP6BBADjQRIFhXPxtbMPNG5La0jEvG4mzzd/pYGRFI1tUdMfc6I+5FE2T8NNJHXjdXsPhgWoY=;
Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xj3BR-00080Q-Oh; Tue, 28 Oct 2014 10:35:22 +0100
Message-ID: <544F635D.2000309@polarssl.org>
Date: Tue, 28 Oct 2014 10:35:25 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Eric Rescorla ,  Peter Gutmann 
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.161.199.191
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/T2qH4feZ8V9gGiwaRMVpt4lSNE8
Cc: "" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 09:35:35 -0000

On 27/10/2014 23:10, Eric Rescorla wrote:
> As I said above, I'm principally trying to get rid of negotiation so we have
> one point format for each curve. I could certainly live with requiring 
> uncompressed only for the X9.62 curves and then defining a new, cleaner
> format for the new CFRG curves.
> 
If the goal is to get rid of negotiation, would it be reasonable to say that
implementations MUST support both formats?

Manuel.


From nobody Tue Oct 28 02:56:00 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0052C1A1AE5 for ; Tue, 28 Oct 2014 02:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1IzYPRPjHMm for ; Tue, 28 Oct 2014 02:55:13 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A331A1AD7 for ; Tue, 28 Oct 2014 02:55:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414490113; x=1446026113; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Sa7sAzSrLdia90aqXHDXaNKdcfKnKyYZ6+f7IMC1D4M=; b=O7AWW+A2M2ZEnwjaJM6om7uMqWvRHuMQHnowJaHetDHSq06yaQgEmE8d 3ElHw1/SjLg36kIds7UhWAhzTm0u3T5zyUJi8Rzw4eoNFGzNmcDsLxMNs BonD0f+sX8hSrwPvkFBBinRbcjbx2tEIp+8FJM7ZM0kuacXlvvgY0ikKe 4=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286160515"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 28 Oct 2014 22:55:10 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 22:55:10 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Summary of discussion regarding spontaneuous authentication
Thread-Index: Ac/ylUIT3mNYoSbWTeamZIOhdRBC4g==
Date: Tue, 28 Oct 2014 09:55:08 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D9E37@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZbaeWcxxtfyjZJ9eKddLkKF-L8g
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 09:55:17 -0000

Eric Rescorla  writes:=0A=
=0A=
>If we make this change, we could still leave CertificateRequest in place, =
but=0A=
>it could be empty, just indicating that the server wants some kind of clie=
nt=0A=
>auth and let the client decide. =0A=
=0A=
Just as a data point, I've always done it that way, the client provides=0A=
whatever cert it has to get in and the server decides whether it'll allow=
=0A=
access.  I've never had any reports of problems so far.=0A=
=0A=
(Caveat: Given the almost nonexistent use of client certs the sample size=
=0A=
there probably isn't very large).=0A=
=0A=
Peter.=


From SRS0=TF6k=7T=acm.org=bmoeller@srs.kundenserver.de  Tue Oct 28 03:49:22 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB251A1B7A for ; Tue, 28 Oct 2014 03:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egLb5PPPlE3k for ; Tue, 28 Oct 2014 03:49:21 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A821A1B79 for ; Tue, 28 Oct 2014 03:49:20 -0700 (PDT)
Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0MJYJr-1Xg3Wv1KeJ-003A2n; Tue, 28 Oct 2014 11:49:18 +0100
Received: by mail-yk0-f170.google.com with SMTP id 19so158566ykq.29 for ; Tue, 28 Oct 2014 03:49:16 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.36.110 with SMTP id v74mr2019896yha.164.1414493356968; Tue, 28 Oct 2014 03:49:16 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Tue, 28 Oct 2014 03:49:16 -0700 (PDT)
In-Reply-To: 
References:  <1799fe49d54b4d43acc26778b9265c8a@BL2PR03MB419.namprd03.prod.outlook.com> 
Date: Tue, 28 Oct 2014 11:49:16 +0100
Message-ID: 
From: Bodo Moeller 
To: Eric Rescorla 
Content-Type: multipart/alternative; boundary=089e0160c4781470ac05067966e5
X-Provags-ID: V02:K0:5D+vyPrlWqk8eI13XANRlf4R2Vcswj7P43c2WmbdAGq 1eHsaQ16eo0iOEU5vw8Dm1JRYKeCWo7e5f8ArzsJJw1RZaTnlh 6r8mXJEIF7tldum3BsDPqvQ1u+xie3vd/D+5ZKTLslvzvvr/de hYAI0CgXPLwql80FXWjqfMGU9cQfAiqrGw0HcsCXpkqog/zl4N h67y76DtzmBkMxCwv+R6HmR5HlcUZLgNUfBKzcxwnIrrjbtFY7 axGUF0fpbJ5ZA+77Ko0M5PCPWoDSjzZ1fzMNiPjanLnjmzoBZA Emux9b5pROoKjuIyH9ol46PGk34+c5PNODFcd6UQnhsr0jGkvE knBKzQsMqlmr3sQGWkZzTLtpwHFABQxBVLx84F6MI8tF4SG/P/ Cac4wg5dnBqb43TDfnL3A79wWSQajPdFxk6A4J3emh8dMy6bST mC/fU
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FUMUhodAcA1nnsjc-Ocoboxpooc
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 11:12:37 -0000

--089e0160c4781470ac05067966e5
Content-Type: text/plain; charset=UTF-8

Eric Rescorla :

Really what I want is to get rid of point negotiation, because it's yet
> another
> point of complexity and it's not universally implemented anyway. Given that
> people seem to think that compressed points are better, I figured that was
> the way to go. If people prefer to just require uncompressed points (at
> least for the existing X9.63 curves) I could certainly live with that.
>

RFC 4492 requires support for uncompressed format (and uncompressed format
is assumed if the supported point formats extension is omitted), so
switching to compressed format for the existing curves in the next protocol
version appears to be asking for trouble.

Deprecating the supported point formats extension isn't a bad idea, but
then if we want to support compressed format for some of the current
curves, the right way to do that would be to define new NamedCurve values
for these.

Bodo

--089e0160c4781470ac05067966e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Eric=
 Rescorla <ekr@rtfm.com>:

Really what I want is to get rid of point negotiation, becau=
se it's yet another
point of complexity and it's not univ=
ersally implemented anyway. Given that
people seem to think that =
compressed points are better, I figured that was
the way to go. I=
f people prefer to just require uncompressed points (at
least for=
 the existing X9.63 curves) I could certainly live with that.

RFC 4492 requires support for un=
compressed format (and uncompressed format is assumed if the supported poin=
t formats extension is omitted), so switching to compressed format for the =
existing curves in the next protocol version appears to be asking for troub=
le.

Deprecating the supported point formats extens=
ion isn't a bad idea, but then if we want to support compressed format =
for some of the current curves, the right way to do that would be to define=
 new NamedCurve values for these.

Bodo
<=
br>


--089e0160c4781470ac05067966e5--


From nobody Tue Oct 28 04:20:56 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883511A1BAC for ; Tue, 28 Oct 2014 04:19:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Level: 
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GC6I2-vxvDH4 for ; Tue, 28 Oct 2014 04:19:52 -0700 (PDT)
Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028621A1B7A for ; Tue, 28 Oct 2014 04:19:51 -0700 (PDT)
Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1Xj4oX-0004Nm-0Y; Tue, 28 Oct 2014 12:19:49 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1Xj4oW-0003Zu-Oa; Tue, 28 Oct 2014 12:19:48 +0100
From: Florian Weimer 
To: Yuhong Bao 
References: 
Date: Tue, 28 Oct 2014 12:19:48 +0100
In-Reply-To:  (Yuhong Bao's message of "Mon, 27 Oct 2014 19:05:41 -0700")
Message-ID: <877fzka1bf.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sM7CjDjdw2ZtinVlb0d8jgdOhV8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 11:19:54 -0000

* Yuhong Bao:

> I hope that a Internet-Draft prohibiting SSL 3.0 will be next.

RFC 6101 already has status =E2=80=9CHISTORIC=E2=80=9D.  I'm not sure what =
else the
IETF can do.  The cryptographically protected version negotation means
that there is no actual harm in supporting SSL 3.0 along with TLS.
(Same for supporting earlier TLS versions.)


From nobody Tue Oct 28 05:36:50 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0971A88AD for ; Tue, 28 Oct 2014 05:36:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.81
X-Spam-Level: 
X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7_pRtfCVI22 for ; Tue, 28 Oct 2014 05:36:23 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222911A1BED for ; Tue, 28 Oct 2014 05:30:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414499454; x=1446035454; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=9bkl/DlKQI4FkXJEq2HvNxlThilNYyAOB6UDL4ry3ao=; b=TWA6LLYqjUBAYPoooR8NdZQGvDKv0sQmajl0nRgHz5qmmiEPWx5als3v Nvi6fy0PJclgjr/iV7O4OAElXnzmE+HmnBSYH4YsU28ZL5UfGRnkJwYli TIhqbFmOntA1sP2c3IQqOs4M3xSiTqhxUHeO7OC1dxNE+TtK2Qeov1eoQ A=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286178389"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 29 Oct 2014 01:30:49 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 01:30:48 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
Thread-Index: Ac/yqwBtseI0TRehRU2SEkNJzo1nWA==
Date: Tue, 28 Oct 2014 12:30:47 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D9F9E@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z2KrCCvnWBkcFS0wBMtweBVAU1A
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 12:36:27 -0000

Alyssa Rowan  writes:=0A=
>On 24/10/2014 15:55, Peter Gutmann wrote:=0A=
>> Re-doing the crypto to implement and support ECC may happen in five=0A=
>>  to ten years, if there's enough code space in the flash.=0A=
>=0A=
>So, you want to use 768-bit groups=85 for five to ten years=85 yeah, I'm=
=0A=
>not too comfortable with that.=0A=
=0A=
I'm not actually sure where this 768-bit figure came from, I don't see it=
=0A=
anywhere in RFC 3526, which starts at 1536 bits.  Now there is a need for=
=0A=
1024-bit groups to support widespread existing use, but not 768 bits.=0A=
=0A=
>(BTW: Lost, embedded devices; too small to use a 2048-bit group for=85 som=
e=0A=
>reason? RAM?; yet negotiate (768|1024|1536) DHE=85=0A=
=0A=
I've been trying to avoid giving specific examples because then people are=
=0A=
going to focus on individual cases rather than the general problem, but her=
e=0A=
are three real use cases from actual deployed or about-to-be-deployed gear.=
=0A=
=0A=
1. The device has a negative code budget, in that features had to be remove=
d=0A=
elsewhere to make room for the crypto (oh, and a negative CPU budget in tha=
t=0A=
it's really too slow for 1024-bit DH, but we can hold our noses and rely on=
=0A=
session resumption with long-term cacheing).  Adding a few bytes of definit=
ion=0A=
for a TLS extension specifying a 1024-bit group is OK, adding an ECC=0A=
implementation is a complete non-starter.  Currently in the process of bein=
g=0A=
deployed, expected lifetime is until the hardware fails.=0A=
=0A=
2. The device has hard real-time requirements and can't do dynamic memory=
=0A=
allocation, you get a fixed (small) amount of RAM at build time and that's=
=0A=
all.  The ECC routines (from OpenSSL) with their large memory footprint and=
=0A=
allocation and de-allocation of memory can't be used.  DH can.  Already=0A=
deployed but can be upgraded (slightly) in new releases, see (1).=0A=
=0A=
3. The device has gone through a type-approval process and can't be changed=
=0A=
any more barring maintenance (see (1) again).  The vendor won't pay for an =
ECC=0A=
implementation, and even if they did they're not going to restart the whole=
=0A=
type-approval process from scratch.  Rest as for (2).=0A=
=0A=
(In any case ECC is only useful if you can persuade all of your competitors=
 to=0A=
do it as well, since if you implement it any no-one can talk to you it's no=
t=0A=
much use.  Since the competitors will be facing the same issues as 1...3=0A=
above, they probably won't bother with ECC).=0A=
=0A=
>SCADA security - or lack thereof - is a very big problem. I don't agree th=
at=0A=
>specifying groups for future use that we _know_ are too small, helps do=0A=
>anything but make it worse.=0A=
=0A=
SCADA security has very, very different requirements than conventional=0A=
security, because availability trumps everything else.  In addition SCADA=
=0A=
security is actually problems with backdoors, hardcoded passwords, open por=
ts,=0A=
insecure protocols, and a million other things, not the size of the DH key =
you=0A=
use for your TLS handshake.=0A=
=0A=
Adding the ability to secure the DH parameters for existing devices is a sm=
all=0A=
but significant improvement on security over what's currently being done.  =
The=0A=
choice isn't "secure existing stuff even if it may be not-best-practice vs.=
=0A=
recommend that people upgrade to best-practice stuff", it's "secure existin=
g=0A=
stuff or do nothing at all".  Anything that requires hardware changes (bigg=
er=0A=
DH groups, switching to new hardware that can handle ECC) becomes "do=0A=
nothing".  So instead of ten years of slightly-more-secure DH it's ten year=
s=0A=
of no extra security.=0A=
=0A=
(If dkg really doesn't want to add support for the existing groups, I'm hap=
py=0A=
to knock out an Informational RFC with the necessary definitions in that ba=
sed=0A=
on his work, it shouldn't take long at all, and he won't have to put his na=
me=0A=
to any of it).=0A=
=0A=
Peter.=


From SRS0=TF6k=7T=acm.org=bmoeller@srs.kundenserver.de  Tue Oct 28 04:11:58 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7C31A1BCC for ; Tue, 28 Oct 2014 04:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGaGlV4gajYI for ; Tue, 28 Oct 2014 04:11:54 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42DD21A1B9E for ; Tue, 28 Oct 2014 04:10:41 -0700 (PDT)
Received: from mail-yh0-f52.google.com (mail-yh0-f52.google.com [209.85.213.52]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0M8hmN-1Y4Igf3EZv-00wFtu; Tue, 28 Oct 2014 12:10:39 +0100
Received: by mail-yh0-f52.google.com with SMTP id a41so179268yho.25 for ; Tue, 28 Oct 2014 04:10:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.108.164 with SMTP id q24mr1998252yhg.131.1414494635634;  Tue, 28 Oct 2014 04:10:35 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Tue, 28 Oct 2014 04:10:35 -0700 (PDT)
In-Reply-To: <20141027193831.EF06C1AF5A@ld9781.wdf.sap.corp>
References:  <20141027193831.EF06C1AF5A@ld9781.wdf.sap.corp>
Date: Tue, 28 Oct 2014 12:10:35 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c1c9fc4b3ac2050679b270
X-Provags-ID: V02:K0:SA+tfHfwj2mgPPFYZVJOvwKdAv1uNUEztUvnAXnQVlq pTj2UoykBjXm60Lb94h/8BP2P/DHlTzwk6yfuqJ7f8tzuMiPcy utvxo/9QxwfccKN6KPsytjksFu89GL9dVfy1Q4Gzkx+BCqulO9 hzjZ4al8q4DK6bp1njsMLP+3H3YqZIQC1rBUy9mB5Lg6fwgC7R IyIxonfDfkfWK3gkHnAmukMwDffRz3ItbTPsphDt8m//qP2B3b CDexvCpjT0l74worWQdtSLtqDLYeLupA9UNkr5LJuMEe+EjFr6 XkV+zM+p0SuLhxvYpIS3acPpwM5MbrPNQxh7mAm4Bhcknb2dbe FurF+R2hcLyzLtVGNYb8ZUzyUdCaVkDDyb+mu67h1pLU27hosi rof202732SszomxW8vKxJMcCvki8QIoxF0y0hzzMiyLONQzDYi j3hVN
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eolTUqXg9Cuv4bVoZLG02e4P-LI
Subject: Re: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 12:55:05 -0000

--001a11c1c9fc4b3ac2050679b270
Content-Type: text/plain; charset=UTF-8

Martin Rex :


> >> Rather than aborthing the TLS handshake, the server ought to include
> >> a TLS extension in the ServerHello indicating that he recognized a
> >> potentially inappropriate fallback and otherwise continue the TLS
> handshake
> >> in the regular fashion, leaving the decision of whether&how to continue
> >> entirely up to those clients who do perform insecure fallbacks.
>


> > That would work too, but the server would then be doing all the work to
> > send a ServerKeyExchange even if the client is going to abort the
> > connection.
>


> I do believe the server load issue here to be sufficiently close to
> marginal to be irrelevant.
>

Normally, yes (after all, TLS_FALLBACK_SCSV isn't expected to be seen *at
all* as long as everything works well). The kind of scenario I'm thinking
of is one with clients on bad wireless networks, which can lead to rather
frequent spurious handshake failures followed by (inappropriate) fallback
retries.  I just don't think that the additional benefit (per connection)
is worth the additional computational effort (per connection), and the
extra latency: for many clients, there is *no* additional benefit at all.

I'm also concerned about the mechanism being more error-prone if servers
don't respond with a fatal alert.  If it's a warning alert (or other
signal) instead, clients will require additional code to handle this
properly, whereas reacting to a fatal alert is something that all TLS
implementations already know how to do.

We could create a client-side signal that allows the client to specify the
desired AlertLevel, but this again would add further complexity to the
protocol (by making server behavior more complex).


The problem with having the server (rather than the falling-back client)
> abort the connection is that the client has no reliable indicator to
> figure out the reason for connection failures,


You have the fatal alert telling you that the current protocol version with
TLS_FALLBACK_SCSV wasn't right.


> It seems that the response mechanism that you propose would allow the
> > server to confirm to that client that the server noticed that the client
> > noticed that something is wrong. What would really be gained by that,
> > compared to what the current TLS_FALLBACK_SCSV protocol offers?
>


> It would leave the decision whether to abort or continue the handshake
> with the one-and-only connection peer that is (a) doing the fallback
> and (b) in the position to establish another connection and attempt
> another handshake, and (c) query the user interactively if something
> odd is going on.
>

You can basically do the same thing with the TLS_FALLBACK_SCSV mechanism,
it just may require an additional connection.

Fallback retries always *are* a kludge, hence I want to keep the
TLS_FALLBACK_SCSV mechanism very simple and easy to support rather than
optimizing for special scenarios.

Bodo

--001a11c1c9fc4b3ac2050679b270
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Mart=
in Rex <mrex@sap.com>:
=C2=A0

>> Rather than aborthing the TLS handshake, the server ought to inclu=
de

>> a TLS extension in the ServerHello indicating that he recognized a=


>> potentially inappropriate fallback and otherwise continue the TLS =
handshake

>> in the regular fashion, leaving the decision of whether&how to=
 continue

>> entirely up to those clients who do perform insecure fallbacks.
=C2=A0

> That would work too, but the server would then be doing all the work t=
o

> send a ServerKeyExchange even if the client is going to abort the

> connection.
=C2=A0
=

I do believe the server load issue here to be sufficiently close to<=
br>
marginal to be irrelevant.

Normally, ye=
s (after all, TLS_FALLBACK_SCSV isn't expected to be seen *at all* as l=
ong as everything works well). The kind of scenario I'm thinking of is =
one with clients on bad wireless networks, which can lead to rather frequen=
t spurious handshake failures followed by (inappropriate) fallback retries.=
=C2=A0 I just don't think that the additional benefit (per connection) =
is worth the additional computational effort (per connection), and the extr=
a latency: for many clients, there is *no* additional benefit at all.
=


I'm also concerned about the mechanism being more e=
rror-prone if servers don't respond with a fatal alert.=C2=A0 If it'=
;s a warning alert (or other signal) instead, clients will require addition=
al code to handle this properly, whereas reacting to a fatal alert is somet=
hing that all TLS implementations already know how to do.

We could create a client-side signal that allows the client to spec=
ify the desired AlertLevel, but this again would add further complexity to =
the protocol (by making server behavior more complex).

=



The problem with having the server (rather than the falling-back cli=
ent)

abort the connection is that the client has no reliable indicator to

figure out the reason for connection failures,

<=
div>You have the fatal alert telling you that the current protocol version =
with TLS_FALLBACK_SCSV wasn't right.



> It seems that the response mechanism that you propose would allow the<=
br>
> server to confirm to that client that the server noticed that the clie=
nt

> noticed that something is wrong. What would really be gained by that,<=
br>
> compared to what the current TLS_FALLBACK_SCSV protocol offers?
=C2=A0

It would leave the decision whether to abort or continue the handsha=
ke

with the one-and-only connection peer that is (a) doing the fallback

and (b) in the position to establish another connection and attempt

another handshake, and (c) query the user interactively if something

odd is going on.

You can basically do t=
he same thing with the TLS_FALLBACK_SCSV mechanism, it just may require an =
additional connection.

Fallback retries always *ar=
e* a kludge, hence I want to keep the TLS_FALLBACK_SCSV mechanism very simp=
le and easy to support rather than optimizing for special scenarios.
<=
div>
Bodo



--001a11c1c9fc4b3ac2050679b270--


From nobody Tue Oct 28 07:52:27 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08951A8A0B for ; Tue, 28 Oct 2014 07:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSuhdS1FJwix for ; Tue, 28 Oct 2014 07:52:25 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C9F1A89B5 for ; Tue, 28 Oct 2014 07:52:25 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4BEAD2AB2BB; Tue, 28 Oct 2014 14:52:24 +0000 (UTC)
Date: Tue, 28 Oct 2014 14:52:24 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20141028145223.GQ19158@mournblade.imrryr.org>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz>  <544F635D.2000309@polarssl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <544F635D.2000309@polarssl.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d_i2-5a65tPyYn7DWPO8wULvJdY
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 14:52:26 -0000

On Tue, Oct 28, 2014 at 10:35:25AM +0100, Manuel P?gouri?-Gonnard wrote:

> On 27/10/2014 23:10, Eric Rescorla wrote:
> > As I said above, I'm principally trying to get rid of negotiation so we have
> > one point format for each curve. I could certainly live with requiring 
> > uncompressed only for the X9.62 curves and then defining a new, cleaner
> > format for the new CFRG curves.
>
> If the goal is to get rid of negotiation, would it be reasonable to say that
> implementations MUST support both formats?

I think that Bodo's suggestion of separate IANA assignments for
compressed and uncompressed variants of curves makes the most sense.

With that, clients that need to interoperate with TLS <= 1.2 can
send the point format extension indicating uncompressed format for
legacy curves, and include the code points for the legacy
format-ambiguous curves, and send new code points for (some of the
same underlying) curves that have an implied format.

Brand new curves would then ideally be registered with a single
preferred point format that is most suitable for the curve.

-- 
	Viktor.


From nobody Tue Oct 28 07:55:16 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB581A8A03 for ; Tue, 28 Oct 2014 07:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aS860kWcs9c for ; Tue, 28 Oct 2014 07:55:14 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281BC1A89E0 for ; Tue, 28 Oct 2014 07:55:13 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id q5so9589376wiv.1 for ; Tue, 28 Oct 2014 07:55:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=5ATJIdKwQhetcfMOcRlZzGmjwT7RxlAppdAubpQZWIg=; b=Yqi0VtpIPaKXU8oS/gjTDBOh3fNCWHKiJ2p6wd2d+U8w4P88QWbUy3wzvKjJrRAoLA evnh6dyXXFY+TU0h0NVym6jM5Ocyz+H+sHiY8vcyKjS1uFm834aTDRuQDeEZ8451zehv MSBp4WEv/VncNHowXdURsDeKStCKTgQotN5bsyeJwq24M+cdSlRMOhZ8//7uK0se/cdn N80/vqx8QO00+SIXiErvQJVtjEzLXakqh+bRtA7axJ8Ss5yuOTDBamVE2baEZcVakjs1 Iuasx/35DmDOUmdv0tf53WlDGpMVKpbYxFnEu5uAYUDqHwVxfKsBLvZ1KNw6NHs+Ld7S H4ig==
X-Gm-Message-State: ALoCoQmLKE5Kx97Kefxb0vCp9CSN38UhCgNLtx7xGZzRe0yvhagxbC91FhgIMFICU+dalv9TLIir
X-Received: by 10.194.191.163 with SMTP id gz3mr4273784wjc.114.1414508112268;  Tue, 28 Oct 2014 07:55:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Tue, 28 Oct 2014 07:54:32 -0700 (PDT)
In-Reply-To: <20141028145223.GQ19158@mournblade.imrryr.org>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz>  <544F635D.2000309@polarssl.org> <20141028145223.GQ19158@mournblade.imrryr.org>
From: Eric Rescorla 
Date: Tue, 28 Oct 2014 07:54:32 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7ba97f2c90684905067cd51b
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NOP39NbNmG_nEVZ25g8NW1Jl4Nk
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 14:55:15 -0000

--047d7ba97f2c90684905067cd51b
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 28, 2014 at 7:52 AM, Viktor Dukhovni 
wrote:

> On Tue, Oct 28, 2014 at 10:35:25AM +0100, Manuel P?gouri?-Gonnard wrote:
>
> > On 27/10/2014 23:10, Eric Rescorla wrote:
> > > As I said above, I'm principally trying to get rid of negotiation so
> we have
> > > one point format for each curve. I could certainly live with requiring
> > > uncompressed only for the X9.62 curves and then defining a new, cleaner
> > > format for the new CFRG curves.
> >
> > If the goal is to get rid of negotiation, would it be reasonable to say
> that
> > implementations MUST support both formats?
>
> I think that Bodo's suggestion of separate IANA assignments for
> compressed and uncompressed variants of curves makes the most sense.
>
> With that, clients that need to interoperate with TLS <= 1.2 can
> send the point format extension indicating uncompressed format for
> legacy curves, and include the code points for the legacy
> format-ambiguous curves, and send new code points for (some of the
> same underlying) curves that have an implied format.
>
> Brand new curves would then ideally be registered with a single
> preferred point format that is most suitable for the curve.


This seems perfectly reasonable to me.

-Ekr

--047d7ba97f2c90684905067cd51b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Oct 28, 2014 at 7:52 AM, Viktor Dukhovni <=
ietf-dane@dukho=
vni.org> wrote:
On Tue, Oct 28, 2014 at 10:35:25AM +0100, Man=
uel P?gouri?-Gonnard wrote:



> On 27/10/2014 23:10, Eric Rescorla wrote:

> > As I said above, I'm principally trying to get rid of negotia=
tion so we have

> > one point format for each curve. I could certainly live with requ=
iring

> > uncompressed only for the X9.62 curves and then defining a new, c=
leaner

> > format for the new CFRG curves.

>

> If the goal is to get rid of negotiation, would it be reasonable to sa=
y that

> implementations MUST support both formats?




I think that Bodo's suggestion of separate IANA assignments=
 for

compressed and uncompressed variants of curves makes the most sense.



With that, clients that need to interoperate with TLS <=3D 1.2 can

send the point format extension indicating uncompressed format for

legacy curves, and include the code points for the legacy

format-ambiguous curves, and send new code points for (some of the

same underlying) curves that have an implied format.



Brand new curves would then ideally be registered with a single

preferred point format that is most suitable for the curve.

This seems perfectly reasonable to me.

-Ekr


--047d7ba97f2c90684905067cd51b--


From nobody Tue Oct 28 08:54:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9292B1A8916 for ; Tue, 28 Oct 2014 08:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdwr3P2PsIhW for ; Tue, 28 Oct 2014 08:54:28 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781F51A8AE2 for ; Tue, 28 Oct 2014 08:54:27 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id E4529818B4 for ; Tue, 28 Oct 2014 17:54:24 +0200 (EET)
Date: Tue, 28 Oct 2014 17:54:24 +0200
From: Ilari Liusvaara 
To: tls@ietf.org
Message-ID: <20141028155424.GA11643@LK-Perkele-VII>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz>  <544F635D.2000309@polarssl.org> <20141028145223.GQ19158@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20141028145223.GQ19158@mournblade.imrryr.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uFrIyYBJVCjc2DjpfYq-lQA7VNE
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 15:54:30 -0000

On Tue, Oct 28, 2014 at 02:52:24PM +0000, Viktor Dukhovni wrote:
> On Tue, Oct 28, 2014 at 10:35:25AM +0100, Manuel P?gouri?-Gonnard wrote:
> 
> > On 27/10/2014 23:10, Eric Rescorla wrote:
> > > As I said above, I'm principally trying to get rid of negotiation so we have
> > > one point format for each curve. I could certainly live with requiring 
> > > uncompressed only for the X9.62 curves and then defining a new, cleaner
> > > format for the new CFRG curves.
> >
> > If the goal is to get rid of negotiation, would it be reasonable to say that
> > implementations MUST support both formats?
> 
> I think that Bodo's suggestion of separate IANA assignments for
> compressed and uncompressed variants of curves makes the most sense.
> 
> With that, clients that need to interoperate with TLS <= 1.2 can
> send the point format extension indicating uncompressed format for
> legacy curves, and include the code points for the legacy
> format-ambiguous curves, and send new code points for (some of the
> same underlying) curves that have an implied format.
> 
> Brand new curves would then ideally be registered with a single
> preferred point format that is most suitable for the curve.

And the new code points also presumably used the fixed wire format
(whatever that happens to be) for the premaster secret (because that
is another thing that currently assumes X9.63 curves)?

With that in, one could handle anything CFRG might throw at us, and
more.


-Ilari


From nobody Tue Oct 28 09:26:20 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2F81A8F4C for ; Tue, 28 Oct 2014 09:26:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.997
X-Spam-Level: 
X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DauqEhcaKlg6 for ; Tue, 28 Oct 2014 09:26:08 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744A01A9025 for ; Tue, 28 Oct 2014 09:24:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=KOSw+fE3aJvrWuR11y3lRoXm0xoHJdsr6PgoabZqPgM=;  b=Qru1FI9US93iDtTNUfXcwel1fvzSyTDkCf6E2Y7mnfOGr/vTQ2JbbCrhH4X8rOH4REqyDyvTx1pLFYDYehJ6KcgrrcrViUyvixTPWIcYmkNKFvz9FcvPXgUwQPv9SPLlj9lcjZKf90wqiTlzFSPzEQmKqgEL6K9fmOpY2PflqkM=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xj9ZE-0008V9-WD for tls@ietf.org; Tue, 28 Oct 2014 17:24:21 +0100
Message-ID: <544FC339.8010605@polarssl.org>
Date: Tue, 28 Oct 2014 17:24:25 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz>  <544F635D.2000309@polarssl.org> <20141028145223.GQ19158@mournblade.imrryr.org>
In-Reply-To: <20141028145223.GQ19158@mournblade.imrryr.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dUdoZm9oHR2ax1MAov3-AugAwMc
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 16:26:10 -0000

On 28/10/2014 15:52, Viktor Dukhovni wrote:
> On Tue, Oct 28, 2014 at 10:35:25AM +0100, Manuel P?gouri?-Gonnard wrote:
> 
>> On 27/10/2014 23:10, Eric Rescorla wrote:
>>> As I said above, I'm principally trying to get rid of negotiation so we have
>>> one point format for each curve. I could certainly live with requiring 
>>> uncompressed only for the X9.62 curves and then defining a new, cleaner
>>> format for the new CFRG curves.
>>
>> If the goal is to get rid of negotiation, would it be reasonable to say that
>> implementations MUST support both formats?
> 
> I think that Bodo's suggestion of separate IANA assignments for
> compressed and uncompressed variants of curves makes the most sense.
> 
Yes, I didn't see his suggestion when I posted, but now I agree it looks like
the best way to go.

Manuel.


From nobody Tue Oct 28 09:56:59 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFBD1A6EF9 for ; Tue, 28 Oct 2014 09:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id big1PT8b5oC5 for ; Tue, 28 Oct 2014 09:56:56 -0700 (PDT)
Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82CA21A891C for ; Tue, 28 Oct 2014 09:56:56 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.04,803,1406606400";  d="scan'208";a="2501876"
Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge2.cygnacom.com with ESMTP; 28 Oct 2014 12:56:55 -0400
Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 12:56:54 -0400
From: Santosh Chokhani 
To: Martin Thomson , Joseph Salowey 
Thread-Topic: [TLS] Summary of discussion regarding spontaneuous authentication
Thread-Index: AQHP7fDJAlDa05ExwUGd7WlSHO2iupw8VaqAgAAD/4CAAAUPgIAAEZiAgAAZRQCACEJbAIAAajAAgAADmoCAAIf9UA==
Date: Tue, 28 Oct 2014 16:56:53 +0000
Message-ID: <4262AC0DB9856847A2D00EF817E81139243CBD@scygexch10.cygnacom.com>
References:   <20141022125359.GA18704@LK-Perkele-VII>  <20141022132623.GA19894@LK-Perkele-VII>  <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4F98@USMBX1.msg.corp.akamai.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.60.117.7]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GDojpXVD7Tv-LFwuoGs0rK6Klbc
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 16:56:58 -0000

CA list has been a double-edged sword.

For cross certified environments, some clients do not present a valid certi=
ficate when the Server root and the client root are cross certified and bot=
h parties can build valid paths.  Browsers vendors have not fixed this conc=
ern.

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Tuesday, October 28, 2014 12:40 AM
To: Joseph Salowey
Cc: tls@ietf.org
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authenticat=
ion

On 27 October 2014 21:27, Joseph Salowey  wrote:
> While I'm not a huge fan of the certificate authorities list, I'm not=20
> sure that punting this to the application layer is the right thing to do.

Would you be interested perhaps in an optional TLS extension that allows bo=
th client and server to express something about what they are willing to co=
nsider as being authoritative?

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From nobody Tue Oct 28 19:35:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EDB1A1BA5 for ; Tue, 28 Oct 2014 19:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opE9XgAxBzAT for ; Tue, 28 Oct 2014 19:35:31 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468191A6EE7 for ; Tue, 28 Oct 2014 19:35:31 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 060F36A9F0; Wed, 29 Oct 2014 03:35:28 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id BB790443B2; Wed, 29 Oct 2014 03:35:28 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B14E71AF5F; Wed, 29 Oct 2014 03:35:28 +0100 (CET)
In-Reply-To: <544E9A42.9080503@fifthhorseman.net>
To: Daniel Kahn Gillmor 
Date: Wed, 29 Oct 2014 03:35:28 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141029023528.B14E71AF5F@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-YA-owgWI1_urpiHv_n1VO9Ox5s
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 02:35:34 -0000

Daniel Kahn Gillmor wrote:
> 
> The failed handshakes associated with false positive fallback behavior
> are from network glitches, right?  not from poorly-implemented or
> unmaintained servers.

As you can see from 5-years-unfixed annoying broken connection management
in Firefox you should be able to see that a huge amount of problems
of false positives come from poor connection management and poor
heuristics, and some from middlelboxes.  network glitches are probably
quite rare.


> 
> in the face of a network glitch, user agents have three options (browser
> behavior in parens):
> 
>  0) report the connection failure up the stack (browsers: show the user
> the "try again button")
> 
>  1) automatically try the connection again, same as last time
> 
>  2) try the connection again with a fallback handshake
> 
> 
> 
> in the false positive cases that we're discussing here, (1) is probably
> the best option.  doing (2) leads directly to choosing a degraded
> ciphersuite.
> 
> including the SCSV with (2) gives the client an inappropriate_fallback
> alert, which they can use to recognize the false positive situation and
> do (1) instead.


This is a misunderstanding.  You may see much less of the
inappropriate_fallback alerts that you might believe you would.

Apps on top of transport-less SSL implementations, such as
Microsoft's IIS on top of Microsoft SChannel SSP has historically never
written any fatal alerts (from the SChannel SSP) to the network
before closing the connection upon handshake failures.

I don't know what the current state is, but if this behaviour is still
common with Micrsoft IIS, then asking the server to abort with
a fatal alert rather then continuing the handshake with a
ServerHelloExtension might have *MUCH* less of a chance to get
hotfixed into the installed base compared to purely TLS-internal
(i.e. SChannel-only) change similar to Renego-protection,
where the server continues the Handshake (provided that the negotiable
security parameters are still acceptable to the servers own policy),
leaving the decision whether to abort and reconnect up to the client
--because only the client is in the position to perform a reconnect,
and only the client has a chance to keep track on whether and how
often it is doing fallbacks and whether the fallback frequency crosses
some threshold that should not be exceeded without prior explicit
user confirmation.

Continuing the handshake would not require any app-level changes to Servers
that have not been writing fatal SSL alerts to the network before 
connection closure in the past, such as Microsoft IIS, so clients
with fallback heuristics will be in a *MUCH* better position to
recognize and distinguish accidental network glitches or connection
management bugs from attacks.  I expect the false positives to
outnumber attacks by at least three orders of magnitudes.


-Martin


From nobody Wed Oct 29 01:57:29 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B431A1A1D for ; Wed, 29 Oct 2014 01:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1goiluTJll_P for ; Wed, 29 Oct 2014 01:57:24 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82821A1A0F for ; Wed, 29 Oct 2014 01:57:23 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9T8vLS6017431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Oct 2014 04:57:21 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9T8vIoV031984 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 04:57:20 -0400
Message-ID: <1414573038.723.4.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Daniel Kahn Gillmor 
Date: Wed, 29 Oct 2014 09:57:18 +0100
In-Reply-To: <874mupwf0k.fsf@alice.fifthhorseman.net>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com> <544C1BC3.5060204@streamsec.se> <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com> <544E0682.30804@streamsec.se> <1414405551.2543.8.camel@dhcp-2-127.brq.redhat.com> <544E254A.3020501@streamsec.se> <1414408020.2543.13.camel@dhcp-2-127.brq.redhat.com> <544E2E5D.4000805@streamsec.se> <874mupwf0k.fsf@alice.fifthhorseman.net>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/REX6n7ds-p9HLwdhXFyyoYagJt0
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 08:57:28 -0000

On Mon, 2014-10-27 at 14:20 -0400, Daniel Kahn Gillmor wrote:
> On Mon 2014-10-27 07:37:01 -0400, Henrick Hellström wrote:
> > It does however strike me as odd that, as a consequence, a named FFDHE 
> > compatible server, would still be allowed to negotiate DHE cipher suites 
> > with legacy clients that do not even implement RFC 4492, but not with 
> > legacy clients that implement DHE in the exact same way, but also 
> > support a few weak elliptic curves.
> 
> hm, yes, i agree that this is a bad outcome, and as of -02 that does
> appear to be the consequence of the draft.  Thanks for pointing this
> out, Henrick.
> 
> To be clear, i think the problem is:
> 
>  * a compatible server might see a client send a DHE ciphersuite and the
>    NamedCurves extension, but with at least one identified NamedCurve
>    that the server doesn't know.
> 
>  * In this case, the server cannot distinguish the following two peers:
> 
>     A) the client implements this draft, but only implements an unusual
>        FFDHE that the server has never heard of.
> 
>     B) the client does not implement with this draft and happens to
>        implement an elliptic curve that the server has never heard of.
> 
>  * The right logic here is that the server SHOULD NOT select DHE for
>    client A, but MAY select DHE for client B, as when interoperating
>    with any other legacy client implementation.  But the server can't
>    distinguish between these cases.

I wouldn't distinguish between these two cases. If the goal is to
promote interoperability, the DHE ciphersuites should not be negotiated
by a compliant server if there are no curves advertised by the client.

Otherwise in client B case, if the server proceeds with negotiating DHE,
the issue that the draft tries to solve reappears, i.e., a broken
session because the DH parameters presented to client for some reason
are not acceptable by the client (e.g., a java client which only
supports 1024-bit parameters).

> I think there needs to be explicit signalling from the client that it
> understands known FFDHE groups, so that a server can distinguish between
> these cases.
> I see three ways to achieve this goal:

I'd add that:
3) Keep the currently defined behavior (i.e., prefer any other
ciphersuite to DHE if the peers share no common groups).

regards,
Nikos



From nobody Wed Oct 29 02:56:19 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6771A7D81 for ; Wed, 29 Oct 2014 02:56:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.262
X-Spam-Level: 
X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAwI6FCnM2dA for ; Wed, 29 Oct 2014 02:56:09 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B2E1A7D83 for ; Wed, 29 Oct 2014 02:56:02 -0700 (PDT)
Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) by mrelayeu.kundenserver.de (node=mreue002) with ESMTP (Nemesis) id 0MSDwg-1XdOeI0pJ4-00T9iS; Wed, 29 Oct 2014 10:56:00 +0100
Received: by mail-yk0-f173.google.com with SMTP id 131so1114082ykp.18 for ; Wed, 29 Oct 2014 02:55:58 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.170.151.137 with SMTP id s131mr1640764ykc.91.1414576558887;  Wed, 29 Oct 2014 02:55:58 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 29 Oct 2014 02:55:58 -0700 (PDT)
In-Reply-To: <20141029023528.B14E71AF5F@ld9781.wdf.sap.corp>
References: <544E9A42.9080503@fifthhorseman.net> <20141029023528.B14E71AF5F@ld9781.wdf.sap.corp>
Date: Wed, 29 Oct 2014 10:55:58 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113a69104cdd6505068cc5a8
X-Provags-ID: V02:K0:bP6adM0ntQBUndnhMd2oslk4AFTr9af0H0LMoQXKkHs IlQZlaZ8RrhlM9vWiMrMoSqTHCn/4Bv/NfwNQgj67AwYMt3htd HhBjTeo5AgiiufwtstdWa6WBxN7V/N73+ASdL6Tl6TIjwA0gLl 8uL7WiWpnpeUBRs4FB3JRWmnz25ICKUeDdEnQYJ/w4Jw4g0dRZ +G4vznTukE/eQR64BGzhFob0CfmKHuBmwRtepe6Ypw9wBV9/Xy /TQtpiQXy3NfiULp3idRYBdcyiSDmm/UwbEYDUz6WGMWDeGWOm +iCARcWGpd7cn+1l5syRp5UCe+dbuCGCBHYcvlHkZb2EKYaoKG wr6MnCbntA3HPlb2cbYd45OYCRGIAkKFPQoVbKRDBcvnmVeaHi p3GZBFYFlqzxF9WHIka1oI9otUQx8jugXCKAFejZdurB/wHuli 2AWFg
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XSX3_Dcdc8DEfcngewi_mIx0TZI
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 09:56:18 -0000

--001a113a69104cdd6505068cc5a8
Content-Type: text/plain; charset=UTF-8

Martin Rex :

As you can see from 5-years-unfixed annoying broken connection management
> in Firefox you should be able to see that a huge amount of problems
> of false positives come from poor connection management and poor
> heuristics, and some from middlelboxes.  network glitches are probably
> quite rare.
>

I think you have mentioned that issue before, but I must admit that I am
not sure I understand what your concern is. If you are referring to
https://bugzilla.mozilla.org/show_bug.cgi?id=1072382, that's a bug that was
found and fixed *because* TLS_FALLBACK_SCSV was rolled out. How, then, is
this an argument *against* TLS_FALLBACK_SCSV semantics?


Apps on top of transport-less SSL implementations, such as
> Microsoft's IIS on top of Microsoft SChannel SSP has historically never
> written any fatal alerts (from the SChannel SSP) to the network
> before closing the connection upon handshake failures.
>

[Historically, I've even seen TCP RST for what should have been a clean
closure alert, meaning that it was up in the air whether the server's
application data would even be delivered to the client application. But
those servers were quite simply broken.]

I don't know what the current state is, but if this behaviour is still
> common with Micrsoft IIS, then asking the server to abort with
> a fatal alert rather then continuing the handshake with a
> ServerHelloExtension might have *MUCH* less of a chance to get
> hotfixed into the installed base compared to purely TLS-internal
> (i.e. SChannel-only) change similar to Renego-protection,
>

Why's that? If broken servers suppress the alert when they tear down the
connection, that's unfortunate, but they can still tear down the
connection. I wouldn't want to optimize for obsolete broken server
implementations at the expense of servers that get things right.

Continuing the handshake would not require any app-level changes to Servers
> that have not been writing fatal SSL alerts to the network before
> connection closure in the past, such as Microsoft IIS, so clients
> with fallback heuristics will be in a *MUCH* better position to
> recognize and distinguish accidental network glitches or connection
> management bugs from attacks.  I expect the false positives to
> outnumber attacks by at least three orders of magnitudes.


If there's an *actual* attack and the client doesn't continue with the
connection, the attacker can suppress alert details anyway. The alert (if
it gets through) is useful for heuristics; the only definitive protection
is from making sure that the client and server won't exchange application
data.

Bodo

--001a113a69104cdd6505068cc5a8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Mart=
in Rex <mrex@sap.com>:

As you can see from 5-years-unfixed annoying broken connection m=
anagement

in Firefox you should be able to see that a huge amount of problems

of false positives come from poor connection management and poor

heuristics, and some from middlelboxes.=C2=A0 network glitches are probably=


quite rare.

I think you have mentioned =
that issue before, but I must admit that I am not sure I understand what yo=
ur concern is. If you are referring to=C2=A0https://bugzilla.mozilla.org/show_bug.c=
gi?id=3D1072382, that's a bug that was found and fixed *because* TL=
S_FALLBACK_SCSV was rolled out. How, then, is this an argument *against* TL=
S_FALLBACK_SCSV semantics?



Apps on top of transport-less SSL implementations, such as

Microsoft's IIS on top of Microsoft SChannel SSP has historically never=


written any fatal alerts (from the SChannel SSP) to the network

before closing the connection upon handshake failures.

[Historically, I've even seen TCP RST for what should h=
ave been a clean closure alert, meaning that it was up in the air whether t=
he server's application data would even be delivered to the client appl=
ication. But those servers were quite simply broken.]=C2=A0

<=
/div>

I don't know what the current state is, but if this behaviour is still<=
br>
common with Micrsoft IIS, then asking the server to abort with

a fatal alert rather then continuing the handshake with a

ServerHelloExtension might have *MUCH* less of a chance to get

hotfixed into the installed base compared to purely TLS-internal

(i.e. SChannel-only) change similar to Renego-protection,
<=
div>
Why's that? If broken servers suppress the alert whe=
n they tear down the connection, that's unfortunate, but they can still=
 tear down the connection. I wouldn't want to optimize for obsolete bro=
ken server implementations at the expense of servers that get things right.=



Continuing the handshake would not require any app-level changes to Servers=


that have not been writing fatal SSL alerts to the network before

connection closure in the past, such as Microsoft IIS, so clients

with fallback heuristics will be in a *MUCH* better position to

recognize and distinguish accidental network glitches or connection

management bugs from attacks.=C2=A0 I expect the false positives to

outnumber attacks by at least three orders of magnitudes.
=

If there's an *actual* attack and the client doesn't=
 continue with the connection, the attacker can suppress alert details anyw=
ay. The alert (if it gets through) is useful for heuristics; the only defin=
itive protection is from making sure that the client and server won't e=
xchange application data.

Bodo




--001a113a69104cdd6505068cc5a8--


From nobody Wed Oct 29 03:24:36 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2946E1A7004 for ; Wed, 29 Oct 2014 03:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 583vWW5ShhAs for ; Wed, 29 Oct 2014 03:24:33 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A3C1A1ADA for ; Wed, 29 Oct 2014 03:24:33 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9TAOWlf012996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 29 Oct 2014 06:24:32 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9TAOUwb010181 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 29 Oct 2014 06:24:32 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Wed, 29 Oct 2014 11:24:29 +0100
Message-ID: <2380691.37D1lhfy5I@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <20141027221408.23949.47145.idtracker@ietfa.amsl.com>
References: <20141027221408.23949.47145.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZYlMSV3Mj3xRWn9Ty-EyCnDCFkA
Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-03.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 10:24:35 -0000

On Monday 27 October 2014 15:14:08 internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Transport Layer Securit=
y
> Working Group of the IETF.
>=20
>         Title           : The Transport Layer Security (TLS) Protocol=

> Version 1.3 Authors         : Tim Dierks
>                           Eric Rescorla
> =09Filename        : draft-ietf-tls-tls13-03.txt
> =09Pages           : 93
> =09Date            : 2014-10-27
>=20
> Abstract:
>    This document specifies Version 1.3 of the Transport Layer Securit=
y
>    (TLS) protocol.  The TLS protocol provides communications security=

>    over the Internet.  The protocol allows client/server applications=
 to
>    communicate in a way that is designed to prevent eavesdropping,
>    tampering, or message forgery.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tls-tls13-03

It's missing brainpool Elliptic Curve Groups from RFC 7027,
points 26, 27 and 28 in NamedGroup.

Is this an intentional omission?

--=20
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi=
c


From nobody Wed Oct 29 03:44:12 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430111A1ADA for ; Wed, 29 Oct 2014 03:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMgVc9ifZpwS for ; Wed, 29 Oct 2014 03:44:07 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D83A1A8545 for ; Wed, 29 Oct 2014 03:44:07 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9TAi1Qn024125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Oct 2014 06:44:01 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9TAhxo3006921 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 06:44:00 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Wed, 29 Oct 2014 11:43:58 +0100
Message-ID: <5997229.rIz4Dkd6bP@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <877fzka1bf.fsf@mid.deneb.enyo.de>
References:  <877fzka1bf.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cSooWKYuNEnaTCOqdnEBpcxcyrA
Cc: Florian Weimer 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 10:44:10 -0000

On Tuesday 28 October 2014 12:19:48 Florian Weimer wrote:
> * Yuhong Bao:
> > I hope that a Internet-Draft prohibiting SSL 3.0 will be next.
>=20
> RFC 6101 already has status =E2=80=9CHISTORIC=E2=80=9D.  I'm not sure=
 what else the
> IETF can do.  The cryptographically protected version negotation mean=
s
> that there is no actual harm in supporting SSL 3.0 along with TLS.
> (Same for supporting earlier TLS versions.)

Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2 compa=
tible=20
client hello with server support being stated as MAY. Similarly, the va=
lue for=20
SSL 3.0 for record layer in client hello is mentioned as the backwards=20=

compatible option with no mention of recommendation against it.

I'd say an RFC that updates them to a MUST NOT/SHOULD NOT (respectively=
 for=20
SSLv2 and SSLv3, at the very least) is not entirely out of scope...

--=20
Regards,
Hubert Kario


From nobody Wed Oct 29 03:52:09 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850BB1A86E8 for ; Wed, 29 Oct 2014 03:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wdpt1J7yiE7 for ; Wed, 29 Oct 2014 03:51:57 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AC11A86FC for ; Wed, 29 Oct 2014 03:51:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414579903; x=1446115903; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=umxWaD7mdqeuiPYckh9QA4LJF4hnqS/LWRkL7OT2BKw=; b=uEwkNXBJlxopA7JWM6mtYqlAcPDmXcbLfU1s7clfFNWgFN0BW2At/C8N glWr6KgB1LgVMglAhZ96fAIwlELcHxAXvDP3R5TIRucZf+1Q7j/jlznrL 2YcDKWj2nVbP69zRrfK5na+PHFi4YfN+Az96nmEDs0kQitTEkPQ8H/n44 s=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286429566"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 29 Oct 2014 23:51:40 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 23:51:39 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Prohibiting SSL 3.0
Thread-Index: Ac/zZlGbvlFAI7VVQPe7CanDSxlvqw==
Date: Wed, 29 Oct 2014 10:51:39 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DB0B2@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/S0aKYx5megYZo0EskQxTrCc90fE
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 10:52:05 -0000

Hubert Kario  writes:=0A=
=0A=
>Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2 compatib=
le=0A=
>client hello with server support being stated as MAY. =0A=
=0A=
Good grief, it's still allowing SSLv2 after nearly *twenty years*?  This=0A=
should have been MUST NOT for both client and server years ago, and at an=
=0A=
absolute minimum SHOULD NOT SSLv3 as well.=0A=
=0A=
Peter.=


From nobody Wed Oct 29 04:16:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE601A1B2B for ; Wed, 29 Oct 2014 04:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uCko3WQxN7r for ; Wed, 29 Oct 2014 04:16:05 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556161A1AEE for ; Wed, 29 Oct 2014 04:16:05 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9TBG4gs013722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 29 Oct 2014 07:16:04 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9TBG2mA004869 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 29 Oct 2014 07:16:04 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Wed, 29 Oct 2014 12:16:01 +0100
Message-ID: <2907933.P1NLlWJtQy@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <544CAC9D.3090909@streamsec.se>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com> <544CAC9D.3090909@streamsec.se>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OgwGmmIeSAL2aAg0312WpdK6FBM
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 11:16:07 -0000

On Sunday 26 October 2014 09:11:09 Henrick Hellstr=F6m wrote:
> On 2014-10-26 08:09, Nikos Mavrogiannopoulos wrote:
> > Note also, that the current approach will simplify a lot an impleme=
ntation
> > that doesn't want to keep the old DHE key exchange with arbitrary g=
roups
> > (and unlike the other key exchanges in TLS, DHE was the most proble=
matic
> > compatibility-wise so I guess many small implementations would be m=
ore
> > than happy to drop it).
>=20
> I don't know about compatibility issues, but rather see a security is=
sue
> that SSL 3.0 up to TLS 1.2 didn't explicitly require the DHE paramete=
rs
> to have a bit size greater than or equal to the certificate public ke=
y.
> I don't know how common it is for clients that offer DHE cipher suite=
s
> to be able to use the server certificate key for signature verificati=
on,
> but unable to compute a DHE handshake using integers of a comparable
> size. I doesn't seem reasonable to expect this to be a problem of suc=
h
> magnitude, that the standards should keep an acceptance for low(er)
> security (than necessary) in order to keep interoperability with such=

> clients.

That's the case for nearly all implementations of Java. JRE before 1.7 =
support=20
at most 1024 bit DHE, while will support 2048 or 3072 bit RSA just fine=
.
1.8 only increased the limit to (IIRC) 2048 bit for DHE.

--=20
Regards,
Hubert Kario


From nobody Wed Oct 29 04:19:05 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367B11A1B55 for ; Wed, 29 Oct 2014 04:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Level: 
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoaP1Jf6xyy5 for ; Wed, 29 Oct 2014 04:19:01 -0700 (PDT)
Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E981A1A7E for ; Wed, 29 Oct 2014 04:19:01 -0700 (PDT)
Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1XjRHG-0005nV-U2; Wed, 29 Oct 2014 12:18:58 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1XjRHG-0000TU-KD; Wed, 29 Oct 2014 12:18:58 +0100
From: Florian Weimer 
To: Hubert Kario 
References:  <877fzka1bf.fsf@mid.deneb.enyo.de> <5997229.rIz4Dkd6bP@pintsize.usersys.redhat.com>
Date: Wed, 29 Oct 2014 12:18:58 +0100
In-Reply-To: <5997229.rIz4Dkd6bP@pintsize.usersys.redhat.com> (Hubert Kario's message of "Wed, 29 Oct 2014 11:43:58 +0100")
Message-ID: <87tx2np1i5.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tDtaRsOHxTNXknVSLxcUJUziCes
Cc: tls@ietf.org
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 11:19:03 -0000

* Hubert Kario:

> On Tuesday 28 October 2014 12:19:48 Florian Weimer wrote:
>> * Yuhong Bao:
>> > I hope that a Internet-Draft prohibiting SSL 3.0 will be next.
>>=20
>> RFC 6101 already has status =E2=80=9CHISTORIC=E2=80=9D.  I'm not sure wh=
at else the
>> IETF can do.  The cryptographically protected version negotation means
>> that there is no actual harm in supporting SSL 3.0 along with TLS.
>> (Same for supporting earlier TLS versions.)
>
> Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2 compati=
ble=20
> client hello with server support being stated as MAY. Similarly, the valu=
e for=20
> SSL 3.0 for record layer in client hello is mentioned as the backwards=20
> compatible option with no mention of recommendation against it.
>
> I'd say an RFC that updates them to a MUST NOT/SHOULD NOT (respectively f=
or=20
> SSLv2 and SSLv3, at the very least) is not entirely out of scope...

I think the SSLv2 compatible client hello is unrelated to the protocol
version advertised by the client, but I might be mistaken about that.


From nobody Wed Oct 29 04:19:09 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5324F1A1B55 for ; Wed, 29 Oct 2014 04:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVSwMJEV0J37 for ; Wed, 29 Oct 2014 04:19:03 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173B71A1B49 for ; Wed, 29 Oct 2014 04:19:03 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id A6E8381828; Wed, 29 Oct 2014 13:18:59 +0200 (EET)
Date: Wed, 29 Oct 2014 13:18:59 +0200
From: Ilari Liusvaara 
To: Peter Gutmann 
Message-ID: <20141029111859.GA29912@LK-Perkele-VII>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB0B2@uxcn10-5.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB0B2@uxcn10-5.UoA.auckland.ac.nz>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/s8BhgQrJoCpfYIMEdhxf7EtzL3g
Cc: "" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 11:19:05 -0000

On Wed, Oct 29, 2014 at 10:51:39AM +0000, Peter Gutmann wrote:
> Hubert Kario  writes:
> 
> >Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2 compatible
> >client hello with server support being stated as MAY. 
> 
> Good grief, it's still allowing SSLv2 after nearly *twenty years*?  This
> should have been MUST NOT for both client and server years ago, and at an
> absolute minimum SHOULD NOT SSLv3 as well.

Also, one can't even use SSLv2 compatible ClientHello for TLS v1.3 because
TLS v1.3 backward compatiblity mode requires extensions, and SSLv2 can't
pass those.

Checking SSL pulse (which I think scans global Internet, not all kinds of
odd internal sites nobody cares about) gives ~19% for SSLv2 (this isn't
the compatiblity hello, this the whole protocol!), which is scary.


-Ilari


From nobody Wed Oct 29 04:27:05 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAC71A000C for ; Wed, 29 Oct 2014 04:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.339
X-Spam-Level: 
X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBZtUX7N10W3 for ; Wed, 29 Oct 2014 04:27:02 -0700 (PDT)
Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F74E1A000B for ; Wed, 29 Oct 2014 04:27:02 -0700 (PDT)
Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1XjRP2-0005pS-Ex for tls@ietf.org; Wed, 29 Oct 2014 12:27:00 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1XjRP2-0000hC-84 for tls@ietf.org; Wed, 29 Oct 2014 12:27:00 +0100
From: Florian Weimer 
To: "tls\@ietf.org" 
References: <544E9A42.9080503@fifthhorseman.net> <20141029023528.B14E71AF5F@ld9781.wdf.sap.corp> 
Date: Wed, 29 Oct 2014 12:27:00 +0100
In-Reply-To:  (Bodo Moeller's message of "Wed, 29 Oct 2014 10:55:58 +0100")
Message-ID: <87oasvp14r.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NOrjLgPkz0mQrxkgaw8AacwBtiM
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 11:27:03 -0000

* Bodo Moeller:

> I think you have mentioned that issue before, but I must admit that I am
> not sure I understand what your concern is. If you are referring to
> https://bugzilla.mozilla.org/show_bug.cgi?id=1072382, that's a bug that was
> found and fixed *because* TLS_FALLBACK_SCSV was rolled out. How, then, is
> this an argument *against* TLS_FALLBACK_SCSV semantics?

This bug in the fallback logic was actually reported in 2008:

  

My concern is that this bug has tainted the telemetry data collected
by Mozilla, and may have grossly exaggerated the need for fallback.
And as far as I can tell, the patch for bug 1072382 only makes the
fallback less sticky, it still does not result in better reporting of
fallbacks in telemetry data.


From nobody Wed Oct 29 04:30:18 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3E01A000D for ; Wed, 29 Oct 2014 04:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9JajMcoL663 for ; Wed, 29 Oct 2014 04:30:13 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4C81A000B for ; Wed, 29 Oct 2014 04:30:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=V+JyH7gi5Dg7FO4LkLjr4iI5jevl07zbwBZXDQRxtkY=;  b=ODW+FBkUGYFY6Odph9zgeNwgv84L2CLYwEC3WN93R+wd6EuwBP6oYv2y4cJNuHtv11JNNjxJYXfuucwULbnKJ/FlIDDZKAitGIpvOpgyYWkMTIe00vpj0LHUU9SxMociABpQNSaSdrH2uiSwVchiLOpoEsxxrIb35u+mIQ5cEAs=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XjRS1-0001Ea-Kb; Wed, 29 Oct 2014 12:30:05 +0100
Message-ID: <5450CFC1.2020308@polarssl.org>
Date: Wed, 29 Oct 2014 12:30:09 +0100
From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Florian Weimer , Hubert Kario 
References:  <877fzka1bf.fsf@mid.deneb.enyo.de> <5997229.rIz4Dkd6bP@pintsize.usersys.redhat.com> <87tx2np1i5.fsf@mid.deneb.enyo.de>
In-Reply-To: <87tx2np1i5.fsf@mid.deneb.enyo.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NUph6hNnnhMbb3VL8ndZurkCzrg
Cc: tls@ietf.org
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 11:30:16 -0000

On 29/10/2014 12:18, Florian Weimer wrote:
> * Hubert Kario:
> 
>> Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2 compatible 
>> client hello with server support being stated as MAY. Similarly, the value for 
>> SSL 3.0 for record layer in client hello is mentioned as the backwards 
>> compatible option with no mention of recommendation against it.
>>
>> I'd say an RFC that updates them to a MUST NOT/SHOULD NOT (respectively for 
>> SSLv2 and SSLv3, at the very least) is not entirely out of scope...
> 
> I think the SSLv2 compatible client hello is unrelated to the protocol
> version advertised by the client, but I might be mistaken about that.
> 
Unless I'm mistaken, there is no point for a client to send a SSLv2 compatible
ClientHello unless the client is prepared to actually negotiate SSLv2. If think
if fair to say that client MUST NOT do that.

OTOH, accepting an SSLv2 ClientHello on the server makes sense even if the
server will never negotiate SSLv2. So I guess the MAY here is ok.

Manuel.


From SRS0=7rtC=7U=acm.org=bmoeller@srs.kundenserver.de  Wed Oct 29 04:34:08 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358541A001D for ; Wed, 29 Oct 2014 04:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.762
X-Spam-Level: *
X-Spam-Status: No, score=1.762 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maD6zmGx3Oc6 for ; Wed, 29 Oct 2014 04:34:07 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61091A001A for ; Wed, 29 Oct 2014 04:34:06 -0700 (PDT)
Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0MTtPJ-1XaswP0xpR-00QgwR; Wed, 29 Oct 2014 12:34:04 +0100
Received: by mail-yk0-f177.google.com with SMTP id 79so1167236ykr.8 for ; Wed, 29 Oct 2014 04:34:03 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.38.234 with SMTP id a70mr1267061yhb.63.1414582443064; Wed, 29 Oct 2014 04:34:03 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 29 Oct 2014 04:34:02 -0700 (PDT)
In-Reply-To: <87oasvp14r.fsf@mid.deneb.enyo.de>
References: <544E9A42.9080503@fifthhorseman.net> <20141029023528.B14E71AF5F@ld9781.wdf.sap.corp>  <87oasvp14r.fsf@mid.deneb.enyo.de>
Date: Wed, 29 Oct 2014 12:34:02 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c1f68006467605068e246e
X-Provags-ID: V02:K0:pSW3K5kltrCV7A7yF6QOTLQwESj4D0RrOnA/QmAOYbN 590dRUMMkVVJnRv63QOT2uGlzdnXpHtP0wd9g5GvQvWaRQJ/jY BQQkonFVIUusiCBaalv8+ucHz1cicAGx/AmKnVVEvm7TbtdSBo U6FNVmk7GcuVCsNDzl5SmXb1Yc1Nc6qIgKHqRe3CDYpGO7o9cB GblHx1zMV47IPua+rM9F3pQ9Gnf1dq4MTfy1WBNEloKB5FSDIX hRxekZ/8/ZYbmTHRQf3rVgeLR5CmJqWiXuDOeN+CtbOrM5MmmH g/P//Hqwuah4QfeBAiXD0GAUqz1ql0iov7sZCYTFqrNNNZ8DEG Fe5ZwjNqs+Zg3MdR2fK1THvTliy5MuKAZNG0Ybvu0mBMTPX1pg 0fWKfjO9LZV2kadc6Y+iYV8l4AtM9ln0gCEqqxO+4TU937LFn4 mbPKE
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PA1pLEjK32vzLjrzjLP3CYGujQE
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 11:38:04 -0000

--001a11c1f68006467605068e246e
Content-Type: text/plain; charset=UTF-8

Florian Weimer :

This bug in the fallback logic was actually reported in 2008:
>
>   
>

Thanks! That makes it six years old (as a *known* bug -- presumably the
problem is older than that).


My concern is that this bug has tainted the telemetry data collected
> by Mozilla, and may have grossly exaggerated the need for fallback.
>

The folks at Mozilla are well aware of this kind of problem, and that the
number of downgraded handshakes observed is inflated over the number of
handshakes that should have been downgraded.

Bodo

--001a11c1f68006467605068e246e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




--001a11c1f68006467605068e246e--


From SRS0=7rtC=7U=acm.org=bmoeller@srs.kundenserver.de  Wed Oct 29 04:37:43 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B501A001D for ; Wed, 29 Oct 2014 04:37:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level: 
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLCd_OdBX8Sp for ; Wed, 29 Oct 2014 04:37:42 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2201A0035 for ; Wed, 29 Oct 2014 04:37:42 -0700 (PDT)
Received: from mail-yk0-f178.google.com (mail-yk0-f178.google.com [209.85.160.178]) by mrelayeu.kundenserver.de (node=mreue002) with ESMTP (Nemesis) id 0M6JFz-1XzSBs3owV-00yQQ2; Wed, 29 Oct 2014 12:37:40 +0100
Received: by mail-yk0-f178.google.com with SMTP id 9so1196033ykp.9 for ; Wed, 29 Oct 2014 04:37:38 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.229.164 with SMTP id h34mr6318yhq.199.1414582658848; Wed, 29 Oct 2014 04:37:38 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 29 Oct 2014 04:37:38 -0700 (PDT)
In-Reply-To: <877fzka1bf.fsf@mid.deneb.enyo.de>
References:  <877fzka1bf.fsf@mid.deneb.enyo.de>
Date: Wed, 29 Oct 2014 12:37:38 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c1db2ae2e1f005068e30d7
X-Provags-ID: V02:K0:jQrrWSnAdNHuiJedpSmj1Rbf0u3YxOTSD89TEYiBKZX kKup5iOuRX9zkzKTXSmW334eECz3CZGvrqz+t/X5K7l+bCFZK5 /hIw6Cwjt4EEvou+3WCD8ZRr4DehsbKEtoO2tAwr5DuyGP1LZN jfBTcU3NP/FVjz++GcqNPRCRx0P/2XeuEFJuVFR1gydE4HyXjs ukV57RLm1Gku8GWraX6BAT+7zJ5atLYEg2+x1XD4n1+5UHYSQX ye7Kw1YmJHfivyjl0hkYXjqwQbB7FU6lYXvq9IQjID3b04EU1j mvryLUnbmRik1OuytJpWS4E6yOdIOAwTQR8f4OyAA8su6HsFJ+ HEeliBLUF8STZsZlkOuWZB7yGsYP+bNcGm9y5Rm/7P0BCtpjI6 GJDBiuiv5WLBfhw47fJZf1s5SBPTzBG5N7IbiwlpItQEBLiYLg TfW2a
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gsZktOfis_SkRhJeNLj35qLYGto
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 11:38:39 -0000

--001a11c1db2ae2e1f005068e30d7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Florian Weimer :


> > I hope that a Internet-Draft prohibiting SSL 3.0 will be next.
>

The UTA BCP I-D has that (
http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-05), although not
everything is in scope.


> RFC 6101 already has status =E2=80=9CHISTORIC=E2=80=9D.  I'm not sure wha=
t else the
> IETF can do.


I agree, but see RFC 6176 for precedent.

Bodo

--001a11c1db2ae2e1f005068e30d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Flor=
ian Weimer <fw@deneb.enyo.de>:
=C2=A0

> I hope that a Internet-Draft prohibiting SSL 3.0 will be next.

The UTA BCP I-D has that (http://tools.ietf.org/h=
tml/draft-ietf-uta-tls-bcp-05), although not everything is in scope.
=C2=A0

RFC 6101 already has status =E2=80=9CHISTORIC=E2=80=9D.=C2=A0 I'=
m not sure what else the

IETF can do.
=C2=A0
I agree, but see RFC 6176 fo=
r precedent.

Bodo

=



--001a11c1db2ae2e1f005068e30d7--


From nobody Wed Oct 29 04:52:05 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609161A002C for ; Wed, 29 Oct 2014 04:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwdn8vSUVfAi for ; Wed, 29 Oct 2014 04:52:00 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2071A000E for ; Wed, 29 Oct 2014 04:52:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=VOO0aFqoa5qm/MyFX/Y7bXpa7qrmRU/v+BYJVQfJwrY=;  b=iRniZ2aqvSDLmAN907kuGBKfUC3sbJrfzJ4gb4h2kFN6FM3s49+BeiuqxxY7rCy25NNavw8SZXcKelIVhuTUARbF87d5nFLvwMP+uHdynfvwzCQBeFBN4qeol30GWooQirQzStEgh1OBsfhCJdlC3EPvKm7OeI0774FWnqE8YeU=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XjRmw-0001GS-Qi; Wed, 29 Oct 2014 12:51:52 +0100
Message-ID: <5450D4D3.40603@polarssl.org>
Date: Wed, 29 Oct 2014 12:51:47 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Florian Weimer , Hubert Kario 
References:  <877fzka1bf.fsf@mid.deneb.enyo.de> <5997229.rIz4Dkd6bP@pintsize.usersys.redhat.com> <87tx2np1i5.fsf@mid.deneb.enyo.de> <5450CFC1.2020308@polarssl.org>
In-Reply-To: <5450CFC1.2020308@polarssl.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vXi9-Uqi0wORTcTcwB34JUimeCY
Cc: tls@ietf.org
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 11:52:01 -0000

On 29/10/2014 12:30, Manuel Pégourié-Gonnard wrote:
> On 29/10/2014 12:18, Florian Weimer wrote:
>> * Hubert Kario:
>>
>>> Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2 compatible 
>>> client hello with server support being stated as MAY. Similarly, the value for 
>>> SSL 3.0 for record layer in client hello is mentioned as the backwards 
>>> compatible option with no mention of recommendation against it.
>>>
>>> I'd say an RFC that updates them to a MUST NOT/SHOULD NOT (respectively for 
>>> SSLv2 and SSLv3, at the very least) is not entirely out of scope...
>>
>> I think the SSLv2 compatible client hello is unrelated to the protocol
>> version advertised by the client, but I might be mistaken about that.
>>
> Unless I'm mistaken, there is no point for a client to send a SSLv2 compatible
> ClientHello unless the client is prepared to actually negotiate SSLv2. If think
> if fair to say that client MUST NOT do that.
> 
> OTOH, accepting an SSLv2 ClientHello on the server makes sense even if the
> server will never negotiate SSLv2. So I guess the MAY here is ok.
> 
... which is exactly what RFC 6176 says (thanks Bodo for mentioning it, I
totally forgot about it). So maybe the TLS 1.3 draft should just be updated to
refer to RFC 6176 here?

Manuel.


From nobody Wed Oct 29 05:25:54 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67641A00C2 for ; Wed, 29 Oct 2014 05:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.296
X-Spam-Level: ***
X-Spam-Status: No, score=3.296 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvQNgshcPcNb for ; Wed, 29 Oct 2014 05:25:51 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17091A00B0 for ; Wed, 29 Oct 2014 05:25:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=IqfkpOF9DFgnw9WrKT2uoNuLalWdLuckdeE/+aaDXbU=;  b=JPRHNAsJ0Gl7kaxYNQiyNJeBePzXDi7XxBwB/LExkYW7EyyMkWxFzyaYD87BsCyYpRwQIkQldNPsBlgiuCzVANPQdwOh64OK+qbpGj6JIEm+MwveBYRnOcUkeI0yUyAZYjDUU8lB6PtjU0AC4Qhu8QjCu2Ke3t3UAwDyqADiDZ0=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XjSJo-0001IY-Sf; Wed, 29 Oct 2014 13:25:41 +0100
Message-ID: <5450DCC9.3040307@polarssl.org>
Date: Wed, 29 Oct 2014 13:25:45 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos , "tls@ietf.org" ,  Christian Kahlo ,  Peter Gutmann 
References: <1414071393.2511.16.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1414071393.2511.16.camel@dhcp-2-127.brq.redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HDmurXk3Cs-e53FqwYw8LWEt5Fs
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 12:25:52 -0000

Hi,

On 23/10/2014 15:36, Nikos Mavrogiannopoulos wrote:
>  Is there some public server implementing rfc7366? At some point the
> server at eid.vx4.net was sent as one, but it doesn't seem to implement
> the protocol in the published rfc (the NSS people seem to have noticed
> that [0], and my tests agree).
> 
I'm not aware of any other public server implementing RFC 7366, but I'd like to
mention I just implemented it and ran tests against your etm branch, and our
implementations interoperate fine with all the CBC suites we have in common, in
all versions of TLS (I didn't test DTLS yet, though).

My implementation does not interoperate with the one at eid.wx4.net either, when
I enable EtM (fails with a bad_record_mac alert).

I think the use of TLSCipherText.length in RFC 7366 is a bit confusing, since
TLSCipherText is defined in terms of GenericBlockCipher, the very structure that
this RFC is changing. It makes it unclear if the following sentence from RFC
5246 still applies:

   The encrypted data length (TLSCiphertext.length) is one more than the
   sum of SecurityParameters.block_length, TLSCompressed.length,
   SecurityParameters.mac_length, and padding_length.

IMO it should, since moving the MAC outside the encryption does not change the
definition of the final length (though it may change the actual length in case
mac_length is not a multiple of block_length).

I guess the author of the implementation at eid.vx4.net thought otherwise.

Manuel.


From nobody Wed Oct 29 05:50:00 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FB31A00BB for ; Wed, 29 Oct 2014 05:49:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Au8NJa49W3J for ; Wed, 29 Oct 2014 05:49:57 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1ACF1A00B5 for ; Wed, 29 Oct 2014 05:49:56 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id q5so4471115wiv.5 for ; Wed, 29 Oct 2014 05:49:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MyaAcIlTR/zNAmirhUsPQei5SdB+eWAPiwv5ip9zTzQ=; b=E6bC8cqxu6lDoe/QCdaqQHF1KdwtcHWbQjNgI+Piw0P2rNxyaktPXuX/R4gtKtARxu W+CzVBU07S5qT8/0JW2izEnvixcSZ4LkCAFkiCvMGxBq46BE7Bpn4FtrH5BXD1B4Gzee 3z7GslINX3vlu87IHKbBWQvJGFUnSif9ox6zhWOBnfonnSk7czCiBq4PkDjBXdzv7eO4 Qb9qPMtxY4DYYhCpxTTk23cA0QN1o2i/w4cu/Se/OlqiXrry3ct4HSfT8TXq1t5isEdm aEtySOvOfRbeVJZDVx8KX2JguPz40ispxgKlIpVCqcJEOTkj0kYFHcx0oFU51sELG021 FJBw==
X-Gm-Message-State: ALoCoQmiIkZdeYWaFfQmk3DGTso4sTsbXlhMuKuZelOwhgUUKu8vIBTDNsNzfRHuaErXSdCcCH0E
X-Received: by 10.194.79.201 with SMTP id l9mr12280727wjx.59.1414586995451; Wed, 29 Oct 2014 05:49:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Wed, 29 Oct 2014 05:49:15 -0700 (PDT)
In-Reply-To: <2380691.37D1lhfy5I@pintsize.usersys.redhat.com>
References: <20141027221408.23949.47145.idtracker@ietfa.amsl.com> <2380691.37D1lhfy5I@pintsize.usersys.redhat.com>
From: Eric Rescorla 
Date: Wed, 29 Oct 2014 05:49:15 -0700
Message-ID: 
To: Hubert Kario 
Content-Type: multipart/alternative; boundary=047d7bf0d0f65e346105068f33f7
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ncxhbHX8I83IX3hQLi4BkhgkRAQ
Cc: "tls@ietf.org" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-03.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 12:49:59 -0000

--047d7bf0d0f65e346105068f33f7
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 29, 2014 at 3:24 AM, Hubert Kario  wrote:

> On Monday 27 October 2014 15:14:08 internet-drafts@ietf.org wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This draft is a work item of the Transport Layer Security
> > Working Group of the IETF.
> >
> >         Title           : The Transport Layer Security (TLS) Protocol
> > Version 1.3 Authors         : Tim Dierks
> >                           Eric Rescorla
> >       Filename        : draft-ietf-tls-tls13-03.txt
> >       Pages           : 93
> >       Date            : 2014-10-27
> >
> > Abstract:
> >    This document specifies Version 1.3 of the Transport Layer Security
> >    (TLS) protocol.  The TLS protocol provides communications security
> >    over the Internet.  The protocol allows client/server applications to
> >    communicate in a way that is designed to prevent eavesdropping,
> >    tampering, or message forgery.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-tls-tls13-03
>
> It's missing brainpool Elliptic Curve Groups from RFC 7027,
> points 26, 27 and 28 in NamedGroup.
>
> Is this an intentional omission?



Semi-intentional.

In Toronto we discussed triaging the list of curves and I didn't know if the
WG wanted Brainpool on the list. I'll be sending out mail on that in a bit.

-Ekr

--047d7bf0d0f65e346105068f33f7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 29, 2014 at 3:24 AM, Hubert Kario <hkario@redhat.com&g=
t; wrote:
On Mond=
ay 27 October 2014 15:14:08 int=
ernet-drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts

> directories. This draft is a work item of the Transport Layer Security=


> Working Group of the IETF.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0: The Transport Layer Security (TLS) Protocol

> Version 1.3 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Tim Dierks

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Eric Rescorla

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-=
ietf-tls-tls13-03.txt

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: 93

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 : 2014-10-27

>

> Abstract:

>=C2=A0 =C2=A0 This document specifies Version 1.3 of the Transport Laye=
r Security

>=C2=A0 =C2=A0 (TLS) protocol.=C2=A0 The TLS protocol provides communica=
tions security

>=C2=A0 =C2=A0 over the Internet.=C2=A0 The protocol allows client/serve=
r applications to

>=C2=A0 =C2=A0 communicate in a way that is designed to prevent eavesdro=
pping,

>=C2=A0 =C2=A0 tampering, or message forgery.

>

>

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
>

> There's also a htmlized version available at:

> http://tools.ietf.org/html/draft-ietf-tls-tls13-03



It's missing brainpool Elliptic Curve Groups from RFC 7027,

points 26, 27 and 28 in NamedGroup.



Is this an intentional omission?


=

Semi-intentional.

In Toronto we discussed=
 triaging the list of curves and I didn't know if the
WG want=
ed Brainpool on the list. I'll be sending out mail on that in a bit.

-Ekr



--047d7bf0d0f65e346105068f33f7--


From nobody Wed Oct 29 05:51:43 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6801A00C6 for ; Wed, 29 Oct 2014 05:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcY4VVJkxQcf for ; Wed, 29 Oct 2014 05:51:40 -0700 (PDT)
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09E21A00B5 for ; Wed, 29 Oct 2014 05:51:39 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id ex7so1581190wid.14 for ; Wed, 29 Oct 2014 05:51:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=c2+l124Gdkhw3j3B9zxIdfXYUO/4/973vQGrSCh1Xxk=; b=mklYjka5GJM9slfeaEE8acsdSM86sU/WEPaHitfHqSW6vhb2GzGJ2SMugzRNBt89zz /25Zit7bsb/UnbAh+4nDFztGGqG34X349fkwyP0k6a8I7Kn480UZ2qXmRpTewo9s4ipO GcRGfps8g1fq3mP8bJ1Yk/e/VcAp84JZkem5u9O5OgNVqvaZlGQT0EAixTFJPP1WGqWF Zo8y0QsHWQwA1koRkPd36AmpYfMZ7VqDxYoisMAEzFitfLRbFFPah4nKuUMypkQ68/UW AkVNpPrig05uc+AgrP0TtFYqsXmC/0W60+hysKrTHww51OcpdG+MQKXtAAW/V878v9H7 r83Q==
X-Gm-Message-State: ALoCoQkrwbpLbeLesSfxL8uRWNShrQ5clvqpRbdqd4ewU3AtCbrEYMMkCaiaHPVZ7HYzzqrCotUb
X-Received: by 10.194.242.4 with SMTP id wm4mr12029358wjc.61.1414587098533; Wed, 29 Oct 2014 05:51:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Wed, 29 Oct 2014 05:50:58 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB0B2@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB0B2@uxcn10-5.UoA.auckland.ac.nz>
From: Eric Rescorla 
Date: Wed, 29 Oct 2014 05:50:58 -0700
Message-ID: 
To: Peter Gutmann 
Content-Type: multipart/alternative; boundary=089e01419af68326e405068f39db
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ioLajcObDlG_m6VG_rx0A1xU2ws
Cc: "" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 12:51:42 -0000

--089e01419af68326e405068f39db
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 29, 2014 at 3:51 AM, Peter Gutmann 
wrote:

> Hubert Kario  writes:
>
> >Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2
> compatible
> >client hello with server support being stated as MAY.
>
> Good grief, it's still allowing SSLv2 after nearly *twenty years*?  This
> should have been MUST NOT for both client and server years ago, and at an
> absolute minimum SHOULD NOT SSLv3 as well.


I haven't gotten around to rewriting this section yet, but it's on my list

-Ekr


>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--089e01419af68326e405068f39db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 29, 2014 at 3:51 AM, Peter Gutmann <pgut001@cs.auc=
kland.ac.nz> wrote:
H=
ubert Kario <hkar=
io@redhat.com> writes:



>Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2 compa=
tible

>client hello with server support being stated as MAY.



Good grief, it's still allowing SSLv2 after nearly *twenty years=
*?=C2=A0 This

should have been MUST NOT for both client and server years ago, and at an
absolute minimum SHOULD NOT SSLv3 as well.

=
I haven't gotten around to rewriting this section yet, but it's on =
my list

-Ekr
=C2=A0


Peter.


_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--089e01419af68326e405068f39db--


From nobody Wed Oct 29 06:07:43 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0871A00EA for ; Wed, 29 Oct 2014 06:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-2m_dkOvlfd for ; Wed, 29 Oct 2014 06:07:38 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id CE3381A0113 for ; Wed, 29 Oct 2014 06:07:01 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 58190486EE; Wed, 29 Oct 2014 13:07:01 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 4C98E485E4; Wed, 29 Oct 2014 13:07:01 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 345A49803D; Wed, 29 Oct 2014 13:07:01 +0000 (GMT)
Received: from usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 29 Oct 2014 09:07:00 -0400
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.216]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Wed, 29 Oct 2014 09:07:00 -0400
From: "Salz, Rich" 
To: Peter Gutmann , "" 
Date: Wed, 29 Oct 2014 09:06:59 -0400
Thread-Topic: [TLS] Prohibiting SSL 3.0
Thread-Index: Ac/zZlGbvlFAI7VVQPe7CanDSxlvqwAEt5vw
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D4F1C9EC7@USMBX1.msg.corp.akamai.com>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB0B2@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB0B2@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ad78cgQV50rgKw558G7OHy_SsiI
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 13:07:40 -0000

> have been MUST NOT for both client and server years ago, and at an
> absolute minimum SHOULD NOT SSLv3 as well.

Agree.

-- =20
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz



From nobody Wed Oct 29 06:21:21 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121591A00BF for ; Wed, 29 Oct 2014 06:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level: 
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGL9ikHpsa6c for ; Wed, 29 Oct 2014 06:21:16 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84671A00B2 for ; Wed, 29 Oct 2014 06:21:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414588877; x=1446124877; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=JHe4uqwMRN5oqy3/+K6pxq2/0w4YhlqZTQ8f6Mxtcbw=; b=KYmrPagOEpkHVZxtuc26PM+zFOJ/eocVpbQ8rVzRf7DTEyVpsDoBD7M0 BMBMC6jz3AE5GWOKC0CrMK7Wf0OMsFb1Ac6saPXfmbOlVKyuWpQm5DtLs 0O8xYyfVOjfdXPfKoZxTItj2ejVHmjLqXcNdYl9skscsKLNxkOZw7qHHl w=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286443528"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Oct 2014 02:21:14 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 02:21:13 +1300
From: Peter Gutmann 
To: "" , =?iso-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , "Christian Kahlo" 
Thread-Topic: [TLS] rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/zezXuWeYDktXrQwW4s6eeqLonSg==
Date: Wed, 29 Oct 2014 13:21:12 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DB261@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xLRS2UCu1K_OP3b4ZnaYEq4K3pg
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 13:21:19 -0000

Manuel P=E9gouri=E9-Gonnard  writes:=0A=
=0A=
>My implementation does not interoperate with the one at eid.wx4.net either=
,=0A=
>when I enable EtM (fails with a bad_record_mac alert).=0A=
=0A=
So what are people doing to get this?  Ages ago when the draft was first=0A=
published a bunch of implementations interop'd with this, so I wonder what'=
s=0A=
changed?=0A=
=0A=
Peter.=


From nobody Wed Oct 29 06:26:05 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6541A00B9 for ; Wed, 29 Oct 2014 06:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t747sIPJ8HD for ; Wed, 29 Oct 2014 06:25:53 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370AC1A00B5 for ; Wed, 29 Oct 2014 06:25:53 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9TDP6cW015695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Oct 2014 09:25:06 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9TDP3ep012258 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 09:25:05 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Wed, 29 Oct 2014 14:25:02 +0100
Message-ID: <3210934.mtebjy4dFk@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <20141029111859.GA29912@LK-Perkele-VII>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB0B2@uxcn10-5.UoA.auckland.ac.nz> <20141029111859.GA29912@LK-Perkele-VII>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tMjpf535cokpOrM_XC_T4uZkOk0
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 13:26:02 -0000

On Wednesday 29 October 2014 13:18:59 Ilari Liusvaara wrote:
> On Wed, Oct 29, 2014 at 10:51:39AM +0000, Peter Gutmann wrote:
> > Hubert Kario  writes:
> > >Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2
> > >compatible client hello with server support being stated as MAY.
> > 
> > Good grief, it's still allowing SSLv2 after nearly *twenty years*?  This
> > should have been MUST NOT for both client and server years ago, and at an
> > absolute minimum SHOULD NOT SSLv3 as well.
> 
> Also, one can't even use SSLv2 compatible ClientHello for TLS v1.3 because
> TLS v1.3 backward compatiblity mode requires extensions, and SSLv2 can't
> pass those.
> 
> Checking SSL pulse (which I think scans global Internet, not all kinds of
> odd internal sites nobody cares about) gives ~19% for SSLv2 (this isn't
> the compatiblity hello, this the whole protocol!), which is scary.

In my scans (a bit bigger set than SSL Pulse), I see over 1% of servers that 
don't support anything but SSLv2!

I also see a bit smaller set of SSLv2 protocol compatible servers, at ~10%. 
The difference may come from the fact that my test is counting only those that 
have SSLv2 ciphers configured, while Ivan Ristic scanner detects SSLv2 
enabled, but no ciphers set, I'd guess it may count those towards the ~19% 
total.
-- 
Regards,
Hubert Kario


From nobody Wed Oct 29 06:47:14 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376951A0102 for ; Wed, 29 Oct 2014 06:47:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-jZCzVdiYQI for ; Wed, 29 Oct 2014 06:46:58 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B511A0104 for ; Wed, 29 Oct 2014 06:46:55 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9TDkFj1025611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Oct 2014 09:46:15 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9TDkC2t019413 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 09:46:13 -0400
Message-ID: <1414590372.723.47.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Peter Gutmann 
Date: Wed, 29 Oct 2014 14:46:12 +0100
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB261@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB261@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NeN4Q7fR7gicYdinOdSVzh2ehqM
Cc: Christian Kahlo , Manuel =?ISO-8859-1?Q?P=E9gouri=E9-Gonnard?= , "" 
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 13:47:04 -0000

On Wed, 2014-10-29 at 13:21 +0000, Peter Gutmann wrote:
> Manuel Pégourié-Gonnard  writes:
> 
> >My implementation does not interoperate with the one at eid.wx4.net either,
> >when I enable EtM (fails with a bad_record_mac alert).
> 
> So what are people doing to get this?  Ages ago when the draft was first
> published a bunch of implementations interop'd with this, so I wonder what's
> changed?

I believe the description of Manuel and the NSS one [0] are pretty
clear. If that bunch of implementations interoperates with eid.wx4.net
then they don't follow the text in rfc7366. If the text is wrong and
these implementations correct an errata should be submitted to the RFC.

[0]. https://bugzilla.mozilla.org/show_bug.cgi?id=972145

regards,
Nikos



From nobody Wed Oct 29 06:59:26 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6933F1A0107 for ; Wed, 29 Oct 2014 06:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.397
X-Spam-Level: *
X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LBEahTYnEhr for ; Wed, 29 Oct 2014 06:59:16 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FDE1A00F9 for ; Wed, 29 Oct 2014 06:59:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=fR2ur+lLKvi0d+34c7tlqjEDgyALguBfkccj8FnhIG8=;  b=dWz72HdVxdASlonAmSVg1jOpwXuTqng8eGdgH1YrFd4Y8Dsd4xPG4t/oG7n5fjzV5r8L09uTnw8rtfgg0eVl+kmwgDKcUWkY58af1WgFaRKCSZ2cn8Pj5a/ucjCLHUwb2aJSCurLAtT+28ZaUK1H/CynQPKkYGTpdZWPafhU5Jo=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XjTmF-0001Q5-PC; Wed, 29 Oct 2014 14:59:08 +0100
Message-ID: <5450F2B0.9000800@polarssl.org>
Date: Wed, 29 Oct 2014 14:59:12 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Peter Gutmann ,  "" , Christian Kahlo 
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB261@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB261@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NI9QuoG2_qz7NP9-H1jT0BYwA5c
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 13:59:19 -0000

On 29/10/2014 14:21, Peter Gutmann wrote:
> Manuel Pégourié-Gonnard  writes:
> 
>> My implementation does not interoperate with the one at eid.wx4.net either,
>> when I enable EtM (fails with a bad_record_mac alert).
> 
> So what are people doing to get this?

What I'm doing to get this is interpret TLSCipherText.length exactly as it is
defined in RFC 5246 (6.2.3.2, page 22):

   The encrypted data length (TLSCiphertext.length) is one more than the
   sum of SecurityParameters.block_length, TLSCompressed.length,
   SecurityParameters.mac_length, and padding_length.

Apparently to interoperate with the implementation at eid.vx4.net (and with
OpenSSL 1.1.0-dev) one needs to rather interpret it as excluding
SecurityParameters.mac_length. I couldn't find this explicitly stated anywhere.

I strongly agree with Nikos that an erratum should make this explicit if that
was the intention of the document. (Or if this was not the original intention
but you prefer to align on the implementation(s) already deployed to avoid an
interop nightmare.)

Manuel.


From nobody Wed Oct 29 07:21:16 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71001A0167 for ; Wed, 29 Oct 2014 07:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5vCRvoxEg6v for ; Wed, 29 Oct 2014 07:21:07 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181601A0127 for ; Wed, 29 Oct 2014 07:20:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414592418; x=1446128418; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=xHcJ/Jq1slrBgZnZTGndPqdDaGYAyLBi+AgopjHUyns=; b=c7+aRfP65vaom/fw8D2K2NW0hMg9Y00wCJQDCCSUU/KE3p6BCuIFdNtD VAZ1a43t8oE6W4zwPDLcWaCPJr9ohvQ4ImqtAX/OmEDCAvhmTOMFaUJEq T++0ayX+nDKD+VBNEOKN9v93EWoU7Ilmm10EpDNIDBTugAsMR3sRySVpc k=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286448021"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Oct 2014 03:20:16 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 03:20:15 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/zg3T/hLf7eeXZS9uYlCU81TJYDg==
Date: Wed, 29 Oct 2014 14:20:14 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DB2EE@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QJOeYGDJ6QhMhoGW2U0sg3ZZ-U0
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 14:21:12 -0000

Nikos Mavrogiannopoulos  writes:=0A=
=0A=
>I believe the description of Manuel and the NSS one [0] are pretty clear. =
If=0A=
>that bunch of implementations interoperates with eid.wx4.net then they don=
't=0A=
>follow the text in rfc7366.=0A=
=0A=
... or eid.wx4.net was changed after the interop took place, or the RFC tex=
t=0A=
was changed after the interop took place.  If you look at the original text=
,=0A=
it specifies:=0A=
=0A=
  TLSCompressed.length=0A=
=0A=
while the final version specifies:=0A=
=0A=
  TLSCipherText.length=0A=
=0A=
which may be the cause of the problem.  This was introduced in -04, long af=
ter=0A=
the interop tests had been done.  I'll have to dig through email to see why=
=0A=
this happened...=0A=
=0A=
Peter.=


From nobody Wed Oct 29 07:32:43 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35B91A0121 for ; Wed, 29 Oct 2014 07:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Level: 
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpGwpTzdKyy3 for ; Wed, 29 Oct 2014 07:32:34 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8167C1A0162 for ; Wed, 29 Oct 2014 07:32:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414593155; x=1446129155; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=F5nqkMeOjOxbNRTeI/wP0+bUXqfmt2XwANZpidg/KOM=; b=ulBiV3HGXxDwINcVQy6PiYfwATZZZOI2peMQ/nx4nFJn1aHjGYx3NhaY JoDEQgTBYozqJqW++uvr0Ed4TMhs/bhBfV/HN37FBoCwDExudaganH437 aubsdPqQEj1BIV4igdMd38F0F7m+xSSd8+zHaKOZ4FEEHe9Ky7Gwvt9Ir s=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286449134"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Oct 2014 03:32:33 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 03:32:31 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/zhSuMnPT4sluYS4uIZ4wfXRYS+A==
Date: Wed, 29 Oct 2014 14:32:30 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DB32F@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yvAtLORC2FSxX4rgUe52ybvELD8
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 14:32:38 -0000

Nikos Mavrogiannopoulos  writes:=0A=
=0A=
>I believe the description of Manuel and the NSS one [0] are pretty clear. =
If=0A=
>that bunch of implementations interoperates with eid.wx4.net then they don=
't=0A=
>follow the text in rfc7366.=0A=
=0A=
I'm still not clear how NSS interprets this in the way it does.=0A=
TLSCipherText.length is the length of ENC(content + padding + padding_lengt=
h),=0A=
which from section 6.2.3 of RFC 5246 is now the same as TLSCipherText.fragm=
ent=0A=
(since the MAC isn't part of GenericWhateverCipher any more).  So whether y=
ou=0A=
pass in TLSCipherText.length (as per the RFC) or TLSCipherText.fragment (as=
=0A=
NSS does) shouldn't make any difference because they're the same thing.=0A=
=0A=
Peter.=0A=
=0A=


From nobody Wed Oct 29 07:38:47 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2B91A010E for ; Wed, 29 Oct 2014 07:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTxIh6N1PSX5 for ; Wed, 29 Oct 2014 07:38:44 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1BE1A0143 for ; Wed, 29 Oct 2014 07:38:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414593525; x=1446129525; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=hH5KMlWszkxAejWrADHE/GcjG8HRBlAPLOu8qf0ZMds=; b=hbgRVaJCw3HWKh8NHqoxjfZ42gudNs0NzIeen7EEL5Jxh0kpIPhb8tDa VlivwrlQ7qbGLCXq0wj/XYM+wbthlsteMUnbHUVhp6Wp+jTpFZgJb8pGY NQCpiSkD4u1iFWP2YFZwtWOP0cv26YAA0wOH3NdFUqtFihG1t6GE8DIGi U=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286449498"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Oct 2014 03:38:44 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 03:38:42 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/zhgi8JCXtbQeBQ2WtrFxyWH+95A==
Date: Wed, 29 Oct 2014 14:38:41 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yjRa_9PWWtZbCEef0Kt3T8Ovdx8
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 14:38:46 -0000

Manuel P=E9gouri=E9-Gonnard  writes:=0A=
=0A=
>What I'm doing to get this is interpret TLSCipherText.length exactly as it=
 is=0A=
>defined in RFC 5246 (6.2.3.2, page 22):=0A=
>=0A=
>   The encrypted data length (TLSCiphertext.length) is one more than the=
=0A=
>   sum of SecurityParameters.block_length, TLSCompressed.length,=0A=
>   SecurityParameters.mac_length, and padding_length.=0A=
>=0A=
>Apparently to interoperate with the implementation at eid.vx4.net (and wit=
h=0A=
>OpenSSL 1.1.0-dev) one needs to rather interpret it as excluding=0A=
>SecurityParameters.mac_length. I couldn't find this explicitly stated=0A=
>anywhere.=0A=
=0A=
Section 3 of RFC 7366 says:=0A=
=0A=
  In [2] notation the overall packet is then:=0A=
=0A=
   struct {=0A=
          ContentType type;=0A=
          ProtocolVersion version;=0A=
          uint16 length;=0A=
          GenericStream/BlockCipher fragment;=0A=
          opaque MAC;=0A=
          } TLSCiphertext;=0A=
=0A=
   This is identical to the existing TLS layout with the only difference=0A=
   being that the MAC value is moved outside the encrypted data.=0A=
=0A=
>I strongly agree with Nikos that an erratum should make this explicit if t=
hat=0A=
>was the intention of the document. =0A=
=0A=
It does make it explicit, see above.  The previous folks who interop'd with=
=0A=
the eid server seemed to have no problems with it.=0A=
=0A=
Peter.=


From nobody Wed Oct 29 08:07:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92411A0199 for ; Wed, 29 Oct 2014 08:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax977SuSr-dX for ; Wed, 29 Oct 2014 08:07:03 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448791A01D6 for ; Wed, 29 Oct 2014 08:06:58 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id ge10so2702972lab.2 for ; Wed, 29 Oct 2014 08:06:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9ty9EKnxb7LpV7VyAC0+NHAR2y+1+I2BQ1LHey3WL08=; b=XlY3Rgw1yX1aum8279otCTOgP7z4r1nvT2ymV3Wd5XwgB5IbZqJ9bPXCQHCk/92Dw+ wMlTgXOoKTHGEguoN07PY8Jmvvxjzs2ihf69d2WIJegQ6+145g+fUAccqiqf+BKffe+4 YL22OgTtV53AoXPL39yO6sJAaBaCQzvIbT2Izhhbq/PoZsc1JXsPxCa8nOuzZrnQr8wt OS3YhVAuuM0mjyCn+kWke4yw/cr3dLBiWvfPsd8/DTF7G3ytz4T0ReO0ni8PxMq+P0L1 XZ3h60YQLKQuzNGRHdHs/iOgS9LMu+hnWVGHG2kidJFKyQPpy4zJlTXlzKoov8mDPVfg WOaw==
X-Received: by 10.152.120.133 with SMTP id lc5mr12123283lab.62.1414595216544;  Wed, 29 Oct 2014 08:06:56 -0700 (PDT)
Received: from [172.24.249.90] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id k7sm2046344lak.22.2014.10.29.08.06.55 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 08:06:55 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir 
In-Reply-To: <3210934.mtebjy4dFk@pintsize.usersys.redhat.com>
Date: Wed, 29 Oct 2014 17:06:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <13B774E2-45AC-4A6C-B91E-71B2C56C5F6E@gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB0B2@uxcn10-5.UoA.auckland.ac.nz> <20141029111859.GA29912@LK-Perkele-VII> <3210934.mtebjy4dFk@pintsize.usersys.redhat.com>
To: Hubert Kario 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vOuLhKHBibB2cm7iPkSbbX2Q7uM
Cc: tls@ietf.org
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 15:07:08 -0000

> On Oct 29, 2014, at 3:25 PM, Hubert Kario  wrote:
>=20
> On Wednesday 29 October 2014 13:18:59 Ilari Liusvaara wrote:
>> On Wed, Oct 29, 2014 at 10:51:39AM +0000, Peter Gutmann wrote:
>>> Hubert Kario  writes:
>>>> Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2
>>>> compatible client hello with server support being stated as MAY.
>>>=20
>>> Good grief, it's still allowing SSLv2 after nearly *twenty years*?  =
This
>>> should have been MUST NOT for both client and server years ago, and =
at an
>>> absolute minimum SHOULD NOT SSLv3 as well.
>>=20
>> Also, one can't even use SSLv2 compatible ClientHello for TLS v1.3 =
because
>> TLS v1.3 backward compatiblity mode requires extensions, and SSLv2 =
can't
>> pass those.
>>=20
>> Checking SSL pulse (which I think scans global Internet, not all =
kinds of
>> odd internal sites nobody cares about) gives ~19% for SSLv2 (this =
isn't
>> the compatiblity hello, this the whole protocol!), which is scary.
>=20
> In my scans (a bit bigger set than SSL Pulse), I see over 1% of =
servers that=20
> don't support anything but SSLv2!

I think that shows that there is an issue with the scan. A server that =
offers only SSLv2 is not on the web. No modern browser can connect to =
it. Are your scans going by the most popular HTTP sites that also answer =
on port 443?  Or are these really HTTPS sites that are accessed as such?

Yoav



From nobody Wed Oct 29 08:20:46 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B440E1A19E9 for ; Wed, 29 Oct 2014 08:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pw2Eo_50iVC for ; Wed, 29 Oct 2014 08:20:31 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B630E1A0636 for ; Wed, 29 Oct 2014 08:20:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=Q5iv0yzTi0w3HSeDge3ZO8TZ4j6KuKLdLtQVozk/gDE=;  b=WrU3REIuCxq0nTAxwTr+A2LjXyQ64ubQ8SWlWsoMVMUnDkuy9hN4VJ3uUpKe1qIn7Hhvz9Ms9CRazeCmLH3ljU9HJOmGFOMVhS076U5t9D0gmY/CF0kFgIla58Ltmeoo1j/yrzPqS1VA7Y1E3Zd44qnt/AAakNvy8PGh1zwrHgE=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XjV2X-0001Xc-87; Wed, 29 Oct 2014 16:20:01 +0100
Message-ID: <545105A5.9060704@polarssl.org>
Date: Wed, 29 Oct 2014 16:20:05 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Peter Gutmann , "" 
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ewE7hWBhi3s1Xc3LqB1QsJQ7NK8
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 15:20:36 -0000

On 29/10/2014 15:38, Peter Gutmann wrote:
> Manuel Pégourié-Gonnard  writes:
> 
>> What I'm doing to get this is interpret TLSCipherText.length exactly as it is
>> defined in RFC 5246 (6.2.3.2, page 22):
>>
>>   The encrypted data length (TLSCiphertext.length) is one more than the
>>   sum of SecurityParameters.block_length, TLSCompressed.length,
>>   SecurityParameters.mac_length, and padding_length.
>>
>> Apparently to interoperate with the implementation at eid.vx4.net (and with
>> OpenSSL 1.1.0-dev) one needs to rather interpret it as excluding
>> SecurityParameters.mac_length. I couldn't find this explicitly stated
>> anywhere.
> 
> Section 3 of RFC 7366 says:
> 
>   In [2] notation the overall packet is then:
> 
>    struct {
>           ContentType type;
>           ProtocolVersion version;
>           uint16 length;
>           GenericStream/BlockCipher fragment;
>           opaque MAC;
>           } TLSCiphertext;
> 
>    This is identical to the existing TLS layout with the only difference
>    being that the MAC value is moved outside the encrypted data.
> 
Precisely. The *only* difference is (something that doesn't involve the
definition of length), so the definition of the length is unchanged, therefore
it's the one from RFC 5246.

Anyway, let's take it from another angle: TLSCipherText.length is what goes on
the wire, right? So:
1. It has to include the (length of the) MAC.
2. The eid server is contradiction with RFC 7366, since using the length that
goes on the wire to compute/check the MAC makes interop with it fail.

It doesn't get any simpler: is the length used in the MAC the same as the one
going on the wire?

Manuel.


From nobody Wed Oct 29 08:30:25 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2811A0217 for ; Wed, 29 Oct 2014 08:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKRIvqce09QO for ; Wed, 29 Oct 2014 08:30:20 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599B71A01EC for ; Wed, 29 Oct 2014 08:30:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414596620; x=1446132620; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=nCqdD6xBOfrDWvu42pTT7w1KBaUWrauhR6u1sXvUj4A=; b=PqPOsMj4feI28GLAonbiC++hxKOTOez/NQlXqDHn8apm7QMt7CZwkfrp pjWt06UunS0d2xOA0crin7rpw4hC/Q4qqGcUwKxxv4D1FwUMlUZqnEROp yB/UiZ9Rgfn1NeJ2+5GSYtmqsaDEUhRFi5R+swkAX7TXgOw4MVL6Rw59l k=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286452748"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Oct 2014 04:30:18 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 04:30:18 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/zjT4FRw5eOE5fRKuz5tvYgntzng==
Date: Wed, 29 Oct 2014 15:30:17 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DB460@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CPJVDkBc7J7M4eB0V1qNZ1fuYqk
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 15:30:22 -0000

Manuel P=E9gouri=E9-Gonnard  writes:=0A=
=0A=
>The *only* difference is (something that doesn't involve the definition of=
=0A=
>length), so the definition of the length is unchanged, therefore it's the =
one=0A=
>from RFC 5246.=0A=
=0A=
No it isn't.  RFC 7366 moves the MAC outside the GenericXXXCipher fragment,=
 so=0A=
it's no longer included.  In fact it doesn't even make any sense to include=
=0A=
the MAC length, if you tell your code to MAC the length of the ciphertext p=
lus=0A=
the length of the MAC you'll end up MACing 20 or 32 bytes of whatever rando=
m=0A=
data happens to be present at the end of the ciphertext.  TLSCiphertext.len=
gth=0A=
is exactly that, the length of the ciphertext, which in RFC 7366 no longer=
=0A=
includes the MAC.  It's not "TLSCiphertext.length + some other data that's=
=0A=
present at the end of the ciphertext".  Even RFC 5246 supports this, it say=
s:=0A=
=0A=
  The encrypted data length (TLSCiphertext.length) [...]=0A=
=0A=
The MAC is no longer encrypted, so it's not part of the encrypted data leng=
th.=0A=
=0A=
Peter.=


From nobody Wed Oct 29 08:34:06 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6913C1A0117 for ; Wed, 29 Oct 2014 08:34:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlGE01uwdGHD for ; Wed, 29 Oct 2014 08:34:02 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E321A00F7 for ; Wed, 29 Oct 2014 08:34:02 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9TFY1VE021651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 29 Oct 2014 11:34:01 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9TFXwjq009240 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 29 Oct 2014 11:34:00 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Wed, 29 Oct 2014 16:33:58 +0100
Message-ID: <1691312.p9EQZRTQmQ@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <13B774E2-45AC-4A6C-B91E-71B2C56C5F6E@gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB0B2@uxcn10-5.UoA.auckland.ac.nz> <3210934.mtebjy4dFk@pintsize.usersys.redhat.com> <13B774E2-45AC-4A6C-B91E-71B2C56C5F6E@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YP-IQgPDdxQ6yqUliFtaSQCguPY
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 15:34:04 -0000

On Wednesday 29 October 2014 17:06:51 Yoav Nir wrote:
> > On Oct 29, 2014, at 3:25 PM, Hubert Kario  wrote:
> > 
> > On Wednesday 29 October 2014 13:18:59 Ilari Liusvaara wrote:
> >> On Wed, Oct 29, 2014 at 10:51:39AM +0000, Peter Gutmann wrote:
> >>> Hubert Kario  writes:
> >>>> Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2
> >>>> compatible client hello with server support being stated as MAY.
> >>> 
> >>> Good grief, it's still allowing SSLv2 after nearly *twenty years*?  This
> >>> should have been MUST NOT for both client and server years ago, and at
> >>> an
> >>> absolute minimum SHOULD NOT SSLv3 as well.
> >> 
> >> Also, one can't even use SSLv2 compatible ClientHello for TLS v1.3
> >> because
> >> TLS v1.3 backward compatiblity mode requires extensions, and SSLv2 can't
> >> pass those.
> >> 
> >> Checking SSL pulse (which I think scans global Internet, not all kinds of
> >> odd internal sites nobody cares about) gives ~19% for SSLv2 (this isn't
> >> the compatiblity hello, this the whole protocol!), which is scary.
> > 
> > In my scans (a bit bigger set than SSL Pulse), I see over 1% of servers
> > that don't support anything but SSLv2!
> 
> I think that shows that there is an issue with the scan. A server that
> offers only SSLv2 is not on the web. No modern browser can connect to it.
> Are your scans going by the most popular HTTP sites that also answer on
> port 443?  Or are these really HTTPS sites that are accessed as such?

they are very much on the web for IE 6 users

I'm using Alexa top 1 million sites

but I'm not checking if the sites use redirect to https (as the redirect may 
be just for login page, only for admins, etc.) so it may not be actually 
visible for regular visitors

I also don't check for CN mismatch (as some clients don't check CNs too...)

That being said, I didn't verify how reliable are the scan results for SSL2 
Only sites, so yes, it may be even less than 1%.

-- 
Regards,
Hubert Kario


From nobody Wed Oct 29 08:43:59 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118391A1A45 for ; Wed, 29 Oct 2014 08:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vq4RGNw79tb for ; Wed, 29 Oct 2014 08:43:48 -0700 (PDT)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D211A1A42 for ; Wed, 29 Oct 2014 08:43:47 -0700 (PDT)
Received: by mail-lb0-f175.google.com with SMTP id b6so2760047lbj.34 for ; Wed, 29 Oct 2014 08:43:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mmzA/4Mamjq472zbRzoeVJpbf/8EeCY7LQOpJGckHdQ=; b=XW3XHrXKeksOGKvj1nU58tm4W/x8OBr/MHjkSQqjwYzM67giGLmVjC+I1YX0lyQZn3 A+vtaYvgtXzLdBlGWo2WtKcm3v+vygPBqz+tDYvnpYh9VElf9V6FDBEiORxmxP8XJFeN 5ezb4QXGlLC5K7L9ITN4qqZ7zk6Ed7ADJwZNx+FFCwHqXdgfdeAUbYWp6f70Iy6K9wPW uR8tMueygVvgFkkdkDFNMwWHupiKuInBMRhj0pU65aHQ6EYI/iDVvLCOX1hBk8CH1IJw NDjdNjWwgsguva+FVYuF6LDGTtg1wV260MNFzGYS3xsUG4JSj2k9zr3n/BNhkUGKeYEk gjfg==
X-Received: by 10.112.198.226 with SMTP id jf2mr12308651lbc.84.1414597425415;  Wed, 29 Oct 2014 08:43:45 -0700 (PDT)
Received: from [172.24.249.90] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id je9sm2084985lbc.3.2014.10.29.08.43.44 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 08:43:44 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir 
In-Reply-To: <1691312.p9EQZRTQmQ@pintsize.usersys.redhat.com>
Date: Wed, 29 Oct 2014 17:43:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB0B2@uxcn10-5.UoA.auckland.ac.nz> <3210934.mtebjy4dFk@pintsize.usersys.redhat.com> <13B774E2-45AC-4A6C-B91E-71B2C56C5F6E@gmail.com> <1691312.p9EQZRTQmQ@pintsize.usersys.redhat.com>
To: Hubert Kario 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pSb9P-l6STvQy0MR2xCBfK3Y_Qc
Cc: tls@ietf.org
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 15:43:53 -0000

> On Oct 29, 2014, at 5:33 PM, Hubert Kario  wrote:
>=20
> On Wednesday 29 October 2014 17:06:51 Yoav Nir wrote:
>>> On Oct 29, 2014, at 3:25 PM, Hubert Kario  wrote:
>>>=20
>>> On Wednesday 29 October 2014 13:18:59 Ilari Liusvaara wrote:
>>>> On Wed, Oct 29, 2014 at 10:51:39AM +0000, Peter Gutmann wrote:
>>>>> Hubert Kario  writes:
>>>>>> Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2
>>>>>> compatible client hello with server support being stated as MAY.
>>>>>=20
>>>>> Good grief, it's still allowing SSLv2 after nearly *twenty years*? =
 This
>>>>> should have been MUST NOT for both client and server years ago, =
and at
>>>>> an
>>>>> absolute minimum SHOULD NOT SSLv3 as well.
>>>>=20
>>>> Also, one can't even use SSLv2 compatible ClientHello for TLS v1.3
>>>> because
>>>> TLS v1.3 backward compatiblity mode requires extensions, and SSLv2 =
can't
>>>> pass those.
>>>>=20
>>>> Checking SSL pulse (which I think scans global Internet, not all =
kinds of
>>>> odd internal sites nobody cares about) gives ~19% for SSLv2 (this =
isn't
>>>> the compatiblity hello, this the whole protocol!), which is scary.
>>>=20
>>> In my scans (a bit bigger set than SSL Pulse), I see over 1% of =
servers
>>> that don't support anything but SSLv2!
>>=20
>> I think that shows that there is an issue with the scan. A server =
that
>> offers only SSLv2 is not on the web. No modern browser can connect to =
it.
>> Are your scans going by the most popular HTTP sites that also answer =
on
>> port 443?  Or are these really HTTPS sites that are accessed as such?
>=20
> they are very much on the web for IE 6 users

Right. So it=E2=80=99s not like they expect everyone to visit their =
site. They=E2=80=99re either responding to programmatic clients or they =
have their small group of users who keep using IE6 on XP especially for =
accessing those sites.

> I'm using Alexa top 1 million sites
>=20
> but I'm not checking if the sites use redirect to https (as the =
redirect may=20
> be just for login page, only for admins, etc.) so it may not be =
actually=20
> visible for regular visitors
>=20
> I also don't check for CN mismatch (as some clients don't check CNs =
too=E2=80=A6)

Are you validating certificates?  Could some of these sites be showing =
the Apache default page with a self-signed certificate?

> That being said, I didn't verify how reliable are the scan results for =
SSL2=20
> Only sites, so yes, it may be even less than 1%.
>=20
> --=20
> Regards,
> Hubert Kario


From nobody Wed Oct 29 08:47:46 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E7E1A1A42 for ; Wed, 29 Oct 2014 08:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z69lo3W0dvT1 for ; Wed, 29 Oct 2014 08:47:43 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A29D1A044F for ; Wed, 29 Oct 2014 08:47:43 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9TFlfG3002947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Oct 2014 11:47:41 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9TFldrB018530 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 11:47:40 -0400
From: Hubert Kario 
To: Yoav Nir 
Date: Wed, 29 Oct 2014 16:47:38 +0100
Message-ID: <2987632.3MlGsVSLRc@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB0B2@uxcn10-5.UoA.auckland.ac.nz> <1691312.p9EQZRTQmQ@pintsize.usersys.redhat.com> 
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/E609VLXeeANEwTAhmERjoHuu1w4
Cc: tls@ietf.org
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 15:47:45 -0000

On Wednesday 29 October 2014 17:43:42 Yoav Nir wrote:
> > On Oct 29, 2014, at 5:33 PM, Hubert Kario  wrote=
:
> >=20
> > On Wednesday 29 October 2014 17:06:51 Yoav Nir wrote:
> >>> On Oct 29, 2014, at 3:25 PM, Hubert Kario  wro=
te:
> >>>=20
> >>> On Wednesday 29 October 2014 13:18:59 Ilari Liusvaara wrote:
> >>>> On Wed, Oct 29, 2014 at 10:51:39AM +0000, Peter Gutmann wrote:
> >>>>> Hubert Kario  writes:
> >>>>>> Even the TLS 1.3 draft says that a client SHOULD NOT send a SS=
Lv2
> >>>>>> compatible client hello with server support being stated as MA=
Y.
> >>>>>=20
> >>>>> Good grief, it's still allowing SSLv2 after nearly *twenty year=
s*?=20
> >>>>> This
> >>>>> should have been MUST NOT for both client and server years ago,=
 and at
> >>>>> an
> >>>>> absolute minimum SHOULD NOT SSLv3 as well.
> >>>>=20
> >>>> Checking SSL pulse (which I think scans global Internet, not all=
 kinds
> >>>> of
> >>>> odd internal sites nobody cares about) gives ~19% for SSLv2 (thi=
s isn't
> >>>> the compatiblity hello, this the whole protocol!), which is scar=
y.
> >>>=20
> >>> In my scans (a bit bigger set than SSL Pulse), I see over 1% of s=
ervers
> >>> that don't support anything but SSLv2!
> >=20
> > I also don't check for CN mismatch (as some clients don't check CNs=
 too=E2=80=A6)
>=20
> Are you validating certificates?  Could some of these sites be showin=
g the
> Apache default page with a self-signed certificate?

Yes, I'm validating them against the Mozilla set of CA certificates. No=
, the=20
stats exclude sites that serve either self signed or corporate signed=20=

certificates.

--=20
Regards,
Hubert Kario


From nobody Wed Oct 29 09:06:02 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803FB1A1B17 for ; Wed, 29 Oct 2014 09:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl8-x7B8hWAt for ; Wed, 29 Oct 2014 09:05:52 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE59B1A1B0C for ; Wed, 29 Oct 2014 09:05:33 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9TG4tTt024033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Oct 2014 12:04:55 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9TG4rB1005287 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 12:04:54 -0400
Message-ID: <1414598692.723.59.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Peter Gutmann 
Date: Wed, 29 Oct 2014 17:04:52 +0100
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB460@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB460@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cbiga_X-2OyKjlLwRPw7smU4Hug
Cc: "" 
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 16:05:59 -0000

On Wed, 2014-10-29 at 15:30 +0000, Peter Gutmann wrote:
> Manuel Pégourié-Gonnard  writes:
> 
> >The *only* difference is (something that doesn't involve the definition of
> >length), so the definition of the length is unchanged, therefore it's the one
> >from RFC 5246.
> 
> No it isn't.  RFC 7366 moves the MAC outside the GenericXXXCipher fragment, so
> it's no longer included.

I don't think it matter that the MAC is outside the GenericXXXCipher
fragment. TLSCiphertext is defined in RFC7366 as follows:

   struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length;
          GenericBlockCipher fragment;
          opaque MAC;
          } TLSCiphertext;

(for block ciphers at least). That TLSCiphertext.length send on the wire
contains both fragment and MAC length, doesn't it?

regards,
Nikos



From thulasi.goriparthi@gmail.com  Wed Oct 29 04:43:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E2B1A0005 for ; Wed, 29 Oct 2014 04:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.464
X-Spam-Level: **
X-Spam-Status: No, score=2.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FH_RELAY_NODNS=1.451, FREEMAIL_FROM=0.001, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYk9NA7Vrd8f for ; Wed, 29 Oct 2014 04:43:30 -0700 (PDT)
Received: from mwork.nabble.com (unknown [162.253.133.43]) by ietfa.amsl.com (Postfix) with ESMTP id 971671A000D for ; Wed, 29 Oct 2014 04:43:30 -0700 (PDT)
Received: from mtom.nabble.com (unknown [162.253.133.81]) by mwork.nabble.com (Postfix) with ESMTP id BE1A58B1D4F for ; Wed, 29 Oct 2014 04:43:30 -0700 (PDT)
Date: Wed, 29 Oct 2014 04:39:40 -0700 (MST)
From: Thulasi 
To: tls@ietf.org
Message-ID: 
In-Reply-To: <20141027221408.23949.47145.idtracker@ietfa.amsl.com>
References: <20141027221408.23949.47145.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_32686_145560214.1414582780580"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oKHxC8hVJYqaS2j3rH7jZ_zHCz0
X-Mailman-Approved-At: Wed, 29 Oct 2014 09:40:24 -0700
Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-03.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 11:45:17 -0000

------=_Part_32686_145560214.1414582780580
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

In Figure 3 (Message flow for an abbreviated handshake),
what does ClientKeyExhange message along with ClientHello signify?

Thanks,

Thulasi.


On 28 October 2014 03:40, Internet-Drafts Administrator [via IETF] <
ml-node+s10n436405h69@n7.nabble.com> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Transport Layer Security Working Group
> of the IETF.
>
>         Title           : The Transport Layer Security (TLS) Protocol
> Version 1.3
>         Authors         : Tim Dierks
>                           Eric Rescorla
>         Filename        : draft-ietf-tls-tls13-03.txt
>         Pages           : 93
>         Date            : 2014-10-27
>
> Abstract:
>    This document specifies Version 1.3 of the Transport Layer Security
>    (TLS) protocol.  The TLS protocol provides communications security
>    over the Internet.  The protocol allows client/server applications to
>    communicate in a way that is designed to prevent eavesdropping,
>    tampering, or message forgery.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tls-tls13-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> TLS mailing list
> [hidden email] 
> https://www.ietf.org/mailman/listinfo/tls
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://ietf.10.n7.nabble.com/I-D-Action-draft-ietf-tls-tls13-03-txt-tp436405.html
>  To start a new topic under IETF - TLS, email
> ml-node+s10n240755h19@n7.nabble.com
> To unsubscribe from IETF - TLS, click here
> 
> .
> NAML
> 
>




--
View this message in context: http://ietf.10.n7.nabble.com/I-D-Action-draft-ietf-tls-tls13-03-txt-tp436405p436714.html
Sent from the IETF - TLS mailing list archive at Nabble.com.
------=_Part_32686_145560214.1414582780580
Content-Type: text/html; charset=UTF8
Content-Transfer-Encoding: quoted-printable


In Figure 3 (Message flow for an abbreviat=
ed handshake),
what does ClientKeyExhange message along with ClientHello=
 signify? 

Thanks,
Thulas=
i.

On 28 October 2014 03:40, Internet-Drafts Administrator [via IETF] <[hidden email]=
> wrote:


=09
A New Internet-Draft is available from the on-line Internet-Drafts d=
irectories.

=C2=A0This draft is a work item of the Transport Layer Security Working=
 Group of the IETF.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 : The Transport Layer Security (TLS) Protocol Version 1.3

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Tim D=
ierks

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Eric Rescorla

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft=
-ietf-tls-tls13-03.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =
93

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: 2014-10-27


Abstract:

=C2=A0 =C2=A0This document specifies Version 1.3 of the Transport Layer=
 Security

=C2=A0 =C2=A0(TLS) protocol.=C2=A0 The TLS protocol provides communicat=
ions security

=C2=A0 =C2=A0over the Internet.=C2=A0 The protocol allows client/server=
 applications to

=C2=A0 =C2=A0communicate in a way that is designed to prevent eavesdrop=
ping,

=C2=A0 =C2=A0tampering, or message forgery.



The IETF datatracker status page for this draft is:

https://datatracker.ietf.=
org/doc/draft-ietf-tls-tls13/

There's also a htmlized versio=
n available at:

http://tools.ietf.org/html/dra=
ft-ietf-tls-tls13-03

A diff from the previous version is availab=
le at:

http://www.ietf.org/rf=
cdiff?url2=3Ddraft-ietf-tls-tls13-03


Please note that it may=
 take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.=
ietf.org.


Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/


_______________________________________________

TLS mailing list

[hidden email]<=
/a>

https://www.ietf.org/mailman/listinfo/t=
ls


=09
=09
=09
=09

=09

=09

=09

=09=09
If you reply to this email, your mess=
age will be added to the discussion below:

=09=09http://ietf.10.n7.nabble.com/I-D-Action-draft-ietf-tls-tls13-03-txt-tp43=
6405.html
=09

=09

=09=09To start a new topic under IETF - TLS, email [hidden email] 

=09=09To unsubscribe from IETF - TLS, click here.

=09=09NAML
=09




=09
=09
=09


View this message in context: Re: I-D Action: dra=
ft-ietf-tls-tls13-03.txt

Sent from the IETF - TLS mailing list archive at Nabble.com.

------=_Part_32686_145560214.1414582780580--


From nobody Wed Oct 29 09:42:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36921A00B9 for ; Wed, 29 Oct 2014 06:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.762
X-Spam-Level: *
X-Spam-Status: No, score=1.762 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_sKaXvcKila for ; Wed, 29 Oct 2014 06:04:13 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B0441A006F for ; Wed, 29 Oct 2014 06:04:13 -0700 (PDT)
Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0M0bdu-1Y4iIO1PUk-00usJB; Wed, 29 Oct 2014 14:04:10 +0100
Received: by mail-yh0-f42.google.com with SMTP id 29so575890yhl.29 for ; Wed, 29 Oct 2014 06:04:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.36.110 with SMTP id v74mr1226378yha.164.1414587847272; Wed, 29 Oct 2014 06:04:07 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 29 Oct 2014 06:04:07 -0700 (PDT)
Date: Wed, 29 Oct 2014 14:04:07 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/mixed; boundary=089e0160c47824197b05068f6680
X-Provags-ID: V02:K0:N2eGbIAyLPwLtP/gUscISawMMw8euE7FzzZheot9Lgt 0Xc3XIoZeAVSlO2VXzDHFpTkFGhOpvNQiu44vkpwx+qo7a/XiE LX6Zb+879Zt3DXzOFVCZOKqqJvulVDFyY6pFBPUupOVc0+0Bzh Uxge/+wJbobckruPXgG5gu6+kuBjpUr0F70nN+HI2XLmSoV8xq k4MWh4T7jg42+OKRiy5YGJni12EGGgcawWoKfXOIPnOaPnaPkY tmbA5YLx3SxocqxQYC2nXCvqK0lhYe2M/5sYgMoX6Ao4QhXcVC G4QS7M+vJCsrvWZpHoM7X5n+ADCzujhtxrJfq2q+YUek3FUAQK HU5vo86MrQHaeWnhu0eGuEcyBNp/pMzTl5ocj15xpET6omu+J8 n/b2Irj9/Hx5nMZUlsXF5ZJWdsg83Qnq9MTyeH7GJoZlxcQ05a zp2+k
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xFfK2Vg1toZIxPO4h3dy0xVtIRo
X-Mailman-Approved-At: Wed, 29 Oct 2014 09:42:10 -0700
Cc: Adam Langley 
Subject: [TLS] Working draft for draft-ietf-tls-downgrade-scsv-01 (and draft-bmoeller-tls-falsestart-01)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 13:04:21 -0000

--089e0160c47824197b05068f6680
Content-Type: multipart/alternative; boundary=089e0160c47824197705068f667e

--089e0160c47824197705068f667e
Content-Type: text/plain; charset=UTF-8

It's past the cut-off for IETF 91 submissions and also none of the authors
may make there, but here (attached) are working drafts for new revisions of
draft-ietf-tls-downgrade-scsv and draft-bmoeller-tls-falsestart. (No
changes to the TLS_FALLBACK_SCSV mechanism, but various clarifications.)

I plan to submit these on November 10 before the main IETF meeting starts,
when the I-D submission tool is reopened.

Bodo

--089e0160c47824197705068f667e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


It's past the cut-off for IETF 91 submissions and also=
 none of the authors may make there, but here (attached) are working drafts=
 for new revisions of draft-ietf-tls-downgrade-scsv and draft-bmoeller-tls-=
falsestart. (No changes to the TLS_FALLBACK_SCSV mechanism, but various cla=
rifications.)

I plan to submit these on November 10=
 before the main IETF meeting starts, when the I-D submission tool is reope=
ned.

Bodo



--089e0160c47824197705068f667e--
--089e0160c47824197b05068f6680
Content-Type: text/plain; charset=US-ASCII; 
	name="DRAFT-draft-ietf-tls-downgrade-scsv-01.txt"
Content-Disposition: attachment; 
	filename="DRAFT-draft-ietf-tls-downgrade-scsv-01.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i1uoscc00

CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgQi4gTW9lbGxlcgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIEEuIExhbmdsZXkKVXBkYXRlczogMjI0NiwgNDM0Niwg
NTI0NiAoaWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgR29vZ2xlCkludGVu
ZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgT2N0b2Jl
ciAyOSwgMjAxNApFeHBpcmVzOiBNYXkgMiwgMjAxNQoKClRMUyBGYWxsYmFjayBTaWduYWxpbmcg
Q2lwaGVyIFN1aXRlIFZhbHVlIChTQ1NWKSBmb3IgUHJldmVudGluZyBQcm90b2NvbAogICAgICAg
ICAgICAgICAgICAgICAgICAgICBEb3duZ3JhZGUgQXR0YWNrcwogICAgICAgICAgICAgICAgIERS
QUZULWRyYWZ0LWlldGYtdGxzLWRvd25ncmFkZS1zY3N2LTAxCgpBYnN0cmFjdAoKICAgVGhpcyBk
b2N1bWVudCBkZWZpbmVzIGEgU2lnbmFsaW5nIENpcGhlciBTdWl0ZSBWYWx1ZSAoU0NTVikgdGhh
dAogICBwcmV2ZW50cyBwcm90b2NvbCBkb3duZ3JhZGUgYXR0YWNrcyBvbiB0aGUgVHJhbnNwb3J0
IExheWVyIFNlY3VyaXR5CiAgIChUTFMpIHByb3RvY29sLiAgSXQgdXBkYXRlcyBSRkMgMjI0Niwg
UkZDIDQzNDYsIGFuZCBSRkMgNTI0Ni4KClN0YXR1cyBvZiBUaGlzIE1lbW8KCiAgIFRoaXMgSW50
ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUKICAg
cHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUg
d29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9y
Y2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAg
IHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJl
bnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
ZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMg
dmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwg
cmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUu
ICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNl
CiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dy
ZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gTWF5IDIsIDIwMTUu
CgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTQgSUVURiBUcnVzdCBhbmQg
dGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCBy
aWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFu
ZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBE
b2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZm
ZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVh
c2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUg
eW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1
bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QK
ICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNl
Y3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlk
ZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNE
IExpY2Vuc2UuCgoKCk1vZWxsZXIgJiBMYW5nbGV5ICAgICAgICAgIEV4cGlyZXMgTWF5IDIsIDIw
MTUgICAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg
ICBUTFMgRmFsbGJhY2sgU0NTViAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxNAoKClRhYmxlIG9m
IENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIFByb3RvY29sIHZhbHVlcyAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgIDMuICBTZXJ2ZXIg
YmVoYXZpb3IgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg
MwogICA0LiAgQ2xpZW50IGJlaGF2aW9yIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAgIDQKICAgNS4gIE9wZXJhdGlvbmFsIENvbnNpZGVyYXRpb25zICAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgIDYuICBTZWN1cml0eSBDb25zaWRl
cmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICA3LiAg
SUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAgIDYKICAgOC4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CiAgICAgOC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMg
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICAgIDguMi4gIEluZm9y
bWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYK
ICAgQXBwZW5kaXggQS4gIEFja25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gICA2CiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNwoKMS4gIEludHJvZHVjdGlvbgoKICAgVG8g
d29yayBhcm91bmQgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyB3aXRoIGxlZ2FjeSBzZXJ2ZXJz
LCBtYW55CiAgIFRMUyBjbGllbnQgaW1wbGVtZW50YXRpb25zIGRvIG5vdCByZWx5IG9uIHRoZSBU
TFMgcHJvdG9jb2wgdmVyc2lvbgogICBuZWdvdGlhdGlvbiBtZWNoYW5pc20gYWxvbmUsIGJ1dCB3
aWxsIGludGVudGlvbmFsbHkgcmVjb25uZWN0IHVzaW5nIGEKICAgZG93bmdyYWRlZCBwcm90b2Nv
bCBpZiBpbml0aWFsIGhhbmRzaGFrZSBhdHRlbXB0cyBmYWlsLiAgU3VjaCBjbGllbnRzCiAgIG1h
eSBmYWxsIGJhY2sgdG8gY29ubmVjdGlvbnMgaW4gd2hpY2ggdGhleSBhbm5vdW5jZSBhIHZlcnNp
b24gYXMgbG93CiAgIGFzIFRMUyAxLjAgKG9yIGV2ZW4gaXRzIHByZWRlY2Vzc29yLCBTU0wgMy4w
KSBhcyB0aGUgaGlnaGVzdAogICBzdXBwb3J0ZWQgdmVyc2lvbi4KCiAgIFdoaWxlIHN1Y2ggZmFs
bGJhY2sgcmV0cmllcyBjYW4gYmUgYSB1c2VmdWwgbGFzdCByZXNvcnQgZm9yCiAgIGNvbm5lY3Rp
b25zIHRvIGFjdHVhbCBsZWdhY3kgc2VydmVycywgdGhlcmUncyBhIHJpc2sgdGhhdCBhY3RpdmUK
ICAgYXR0YWNrZXJzIGNvdWxkIGV4cGxvaXQgdGhlIGRvd25ncmFkZSBzdHJhdGVneSB0byB3ZWFr
ZW4gdGhlCiAgIGNyeXB0b2dyYXBoaWMgc2VjdXJpdHkgb2YgY29ubmVjdGlvbnMuICBBbHNvLCBo
YW5kc2hha2UgZXJyb3JzIGR1ZSB0bwogICBuZXR3b3JrIGdsaXRjaGVzIGNvdWxkIHNpbWlsYXJs
eSBiZSBtaXNpbnRlcnByZXRlZCBhcyBpbnRlcmFjdGlvbgogICB3aXRoIGEgbGVnYWN5IHNlcnZl
ciBhbmQgcmVzdWx0IGluIGEgcHJvdG9jb2wgZG93bmdyYWRlLgoKICAgQWxsIHVubmVjZXNzYXJ5
IHByb3RvY29sIGRvd25ncmFkZXMgYXJlIHVuZGVzaXJhYmxlIChlLmcuLCBmcm9tIFRMUwogICAx
LjIgdG8gVExTIDEuMSBpZiBib3RoIHRoZSBjbGllbnQgYW5kIHRoZSBzZXJ2ZXIgYWN0dWFsbHkg
ZG8gc3VwcG9ydAogICBUTFMgMS4yKTsgdGhleSBjYW4gYmUgcGFydGljdWxhcmx5IGNyaXRpY2Fs
IGlmIHRoZXkgbWVhbiBsb3NpbmcgdGhlCiAgIFRMUyBleHRlbnNpb24gZmVhdHVyZSAod2hlbiBk
b3duZ3JhZGluZyB0byBTU0wgMy4wKS4gIFRoaXMgZG9jdW1lbnQKICAgZGVmaW5lcyBhIFNpZ25h
bGluZyBDaXBoZXIgU3VpdGUgVmFsdWUgKFNDU1YpIHRoYXQgY2FuIGJlIGVtcGxveWVkIHRvCiAg
IHByZXZlbnQgdW5pbnRlbmRlZCBwcm90b2NvbCBkb3duZ3JhZGVzIGJldHdlZW4gY2xpZW50cyBh
bmQgc2VydmVycwogICB0aGF0IGNvbXBseSB0byB0aGlzIGRvY3VtZW50LCBieSBoYXZpbmcgdGhl
IGNsaWVudCBpbmRpY2F0ZSB0aGF0IHRoZQogICBjdXJyZW50IGNvbm5lY3Rpb24gYXR0ZW1wdCBp
cyBtZXJlbHkgYSBmYWxsYmFjaywgYW5kIGJ5IGhhdmluZyB0aGUKICAgc2VydmVyIHJldHVybiBh
IGZhdGFsIGFsZXJ0IGlmIGl0IGRldGVjdHMgYW4gaW5hcHByb3ByaWF0ZSBmYWxsYmFjay4KICAg
KFRoZSBhbGVydCBkb2VzIG5vdCBuZWNlc3NhcmlseSBpbmRpY2F0ZSBhbiBpbnRlbnRpb25hbCBk
b3duZ3JhZGUKICAgYXR0YWNrLCBzaW5jZSBuZXR3b3JrIGdsaXRjaGVzIHRvbyBjb3VsZCByZXN1
bHQgaW4gaW5hcHByb3ByaWF0ZQogICBmYWxsYmFjayByZXRyaWVzLikKCiAgIFRoaXMgc3BlY2lm
aWNhdGlvbiBhcHBsaWVzIHRvIGltcGxlbWVudGF0aW9ucyBvZiBUTFMgMS4wIFtSRkMyMjQ2XSwK
ICAgVExTIDEuMSBbUkZDNDM0Nl0sIGFuZCBUTFMgMS4yIFtSRkM1MjQ2XS4gIChJdCBpcyBwYXJ0
aWN1bGFybHkKICAgcmVsZXZhbnQgaWYgc3VjaCBpbXBsZW1lbnRhdGlvbnMgYWxzbyBpbmNsdWRl
IHN1cHBvcnQgZm9yIHByZWRlY2Vzc29yCgoKCk1vZWxsZXIgJiBMYW5nbGV5ICAgICAgICAgIEV4
cGlyZXMgTWF5IDIsIDIwMTUgICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURy
YWZ0ICAgICAgICAgICAgICBUTFMgRmFsbGJhY2sgU0NTViAgICAgICAgICAgICAgIE9jdG9iZXIg
MjAxNAoKCiAgIHByb3RvY29sIFNTTCAzLjAgW1JGQzYxMDFdLikgIEl0IGNhbiBiZSBhcHBsaWVk
IHNpbWlsYXJseSB0byBsYXRlcgogICBwcm90b2NvbCB2ZXJzaW9ucy4KCiAgIFRoZSBrZXkgd29y
ZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwK
ICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BU
SU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2Ny
aWJlZCBpbiBbUkZDMjExOV0uCgoyLiAgUHJvdG9jb2wgdmFsdWVzCgogICBUaGlzIGRvY3VtZW50
IGRlZmluZXMgYSBuZXcgVExTIGNpcGhlciBzdWl0ZSB2YWx1ZToKCiAgICAgICAgVExTX0ZBTExC
QUNLX1NDU1YgICAgICAgICAgezB4NTYsIDB4MDB9CgogICBUaGlzIGlzIGEgc2lnbmFsaW5nIGNp
cGhlciBzdWl0ZSB2YWx1ZSAoU0NTViksIGkuZS4sIGl0IGRvZXMgbm90CiAgIGFjdHVhbGx5IGNv
cnJlc3BvbmQgdG8gYSBzdWl0ZSBvZiBjcnlwdG9zeXN0ZW1zLCBhbmQgaXQgY2FuIG5ldmVyIGJl
CiAgIHNlbGVjdGVkIGJ5IHRoZSBzZXJ2ZXIgaW4gdGhlIGhhbmRzaGFrZTsgcmF0aGVyLCBpdHMg
cHJlc2VuY2UgaW4gdGhlCiAgIENsaWVudCBIZWxsbyBtZXNzYWdlIHNlcnZlcyBhcyBhIGJhY2t3
YXJkcy1jb21wYXRpYmxlIHNpZ25hbCBmcm9tIHRoZQogICBjbGllbnQgdG8gdGhlIHNlcnZlci4K
CiAgIFRoaXMgZG9jdW1lbnQgYWxzbyBhbGxvY2F0ZXMgYSBuZXcgYWxlcnQgdmFsdWUgaW4gdGhl
IFRMUyBBbGVydAogICBSZWdpc3RyeSBbUkZDNTI0Nl06CgogICAgICAgIGVudW0gewogICAgICAg
ICAgLyogLi4uICovCiAgICAgICAgICBpbmFwcHJvcHJpYXRlX2ZhbGxiYWNrKDg2KSwKICAgICAg
ICAgIC8qIC4uLiAqLwogICAgICAgICAgKDI1NSkKICAgICAgICB9IEFsZXJ0RGVzY3JpcHRpb247
CgogICBUaGlzIGFsZXJ0IGlzIG9ubHkgZ2VuZXJhdGVkIGJ5IHNlcnZlcnMsIGFzIGRlc2NyaWJl
ZCBpbiBTZWN0aW9uIDMuCiAgIEl0IGlzIGFsd2F5cyBmYXRhbC4KCjMuICBTZXJ2ZXIgYmVoYXZp
b3IKCiAgIFRoaXMgc2VjdGlvbiBzcGVjaWZpZXMgc2VydmVyIGJlaGF2aW9yIHdoZW4gcmVjZWl2
aW5nIHRoZQogICBUTFNfRkFMTEJBQ0tfU0NTViBjaXBoZXIgc3VpdGUgZnJvbSBhIGNsaWVudCBp
bgogICBDbGllbnRIZWxsby5jaXBoZXJfc3VpdGVzLgoKICAgbyAgSWYgVExTX0ZBTExCQUNLX1ND
U1YgYXBwZWFycyBpbiBDbGllbnRIZWxsby5jaXBoZXJfc3VpdGVzIGFuZCB0aGUKICAgICAgaGln
aGVzdCBwcm90b2NvbCB2ZXJzaW9uIHN1cHBvcnRlZCBieSB0aGUgc2VydmVyIGlzIGhpZ2hlciB0
aGFuCiAgICAgIHRoZSB2ZXJzaW9uIGluZGljYXRlZCBpbiBDbGllbnRIZWxsby5jbGllbnRfdmVy
c2lvbiwgdGhlIHNlcnZlcgogICAgICBNVVNUIHJlc3BvbmQgd2l0aCBhIGZhdGFsIGluYXBwcm9w
cmlhdGVfZmFsbGJhY2sgYWxlcnQuCgogICBvICBPdGhlcndpc2UgKGVpdGhlciBUTFNfRkFMTEJB
Q0tfU0NTViBkb2VzIG5vdCBhcHBlYXIsIG9yIGl0IGFwcGVhcnMKICAgICAgYW5kIHRoZSBjbGll
bnQncyBwcm90b2NvbCB2ZXJzaW9uIGlzIGF0IGxlYXN0IHRoZSBoaWdoZXN0IHByb3RvY29sCiAg
ICAgIHZlcnNpb24gc3VwcG9ydGVkIGJ5IHRoZSBzZXJ2ZXIpLCB0aGUgc2VydmVyIHByb2NlZWRz
IHdpdGggdGhlCiAgICAgIGhhbmRzaGFrZSBhcyB1c3VhbC4KCgoKCk1vZWxsZXIgJiBMYW5nbGV5
ICAgICAgICAgIEV4cGlyZXMgTWF5IDIsIDIwMTUgICAgICAgICAgICAgICAgICBbUGFnZSAzXQoM
CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBUTFMgRmFsbGJhY2sgU0NTViAgICAgICAgICAg
ICAgIE9jdG9iZXIgMjAxNAoKCiAgIChBIHByb3RvY29sIHZlcnNpb24gaXMgc3VwcG9ydGVkIGJ5
IHRoZSBzZXJ2ZXIgaWYsIGluIHJlc3BvbnNlIHRvCiAgIGFwcHJvcHJpYXRlIENsaWVudCBIZWxs
byBtZXNzYWdlcywgdGhlIHNlcnZlciB3b3VsZCB1c2UgaXQgZm9yCiAgIFNlcnZlckhlbGxvLnNl
cnZlcl92ZXJzaW9uLiAgSWYgYSBwYXJ0aWN1bGFyIHByb3RvY29sIHZlcnNpb24gaXMKICAgaW1w
bGVtZW50ZWQgYnV0IGNvbXBsZXRlbHkgZGlzYWJsZWQgYnkgc2VydmVyIHNldHRpbmdzLCBpdCBp
cyBub3QKICAgY29uc2lkZXJlZCBzdXBwb3J0ZWQuICBGb3IgZXhhbXBsZSwgaWYgdGhlIGltcGxl
bWVudGF0aW9uJ3MgaGlnaGVzdAogICBwcm90b2NvbCB2ZXJzaW9uIGlzIFRMUyAxLjIgYnV0IHRo
ZSBzZXJ2ZXIgb3BlcmF0b3IgaGFzIGRpc2FibGVkIHRoaXMKICAgdmVyc2lvbiwgYSBUTFMgMS4x
IENsaWVudCBIZWxsbyB3aXRoIFRMU19GQUxMQkFDS19TQ1NWIGRvZXMgbm90CiAgIHdhcnJhbnQg
cmVzcG9uZGluZyB3aXRoIGFuIGluYXBwb3ByaWF0ZV9mYWxsYmFjayBhbGVydC4pCgo0LiAgQ2xp
ZW50IGJlaGF2aW9yCgogICBUaGUgVExTX0ZBTExCQUNLX1NDU1YgY2lwaGVyIHN1aXRlIHZhbHVl
IGlzIG1lYW50IGZvciB1c2UgYnkgY2xpZW50cwogICB0aGF0IHJlcGVhdCBhIGNvbm5lY3Rpb24g
YXR0ZW1wdCB3aXRoIGEgZG93bmdyYWRlZCBwcm90b2NvbCAocGVyZm9ybQogICBhICJmYWxsYmFj
ayByZXRyeSIpIGluIG9yZGVyIHRvIHdvcmsgYXJvdW5kIGludGVyb3BlcmFiaWxpdHkgcHJvYmxl
bXMKICAgd2l0aCBsZWdhY3kgc2VydmVycy4KCiAgIG8gIElmIGEgY2xpZW50IHNlbmRzIGEgQ2xp
ZW50SGVsbG8uY2xpZW50X3ZlcnNpb24gY29udGFpbmluZyBhIGxvd2VyCiAgICAgIHZhbHVlIHRo
YW4gdGhlIGxhdGVzdCAoaGlnaGVzdC12YWx1ZWQpIHZlcnNpb24gc3VwcG9ydGVkIGJ5IHRoZQog
ICAgICBjbGllbnQsIGl0IFNIT1VMRCBpbmNsdWRlIHRoZSBUTFNfRkFMTEJBQ0tfU0NTViBjaXBo
ZXIgc3VpdGUgdmFsdWUKICAgICAgaW4gQ2xpZW50SGVsbG8uY2lwaGVyX3N1aXRlcy4gIChTaW5j
ZSB0aGUgY2lwaGVyIHN1aXRlIGxpc3QgaW4gdGhlCiAgICAgIENsaWVudEhlbGxvIGlzIG9yZGVy
ZWQgYnkgcHJlZmVyZW5jZSwgd2l0aCB0aGUgY2xpZW50J3MgZmF2b3JpdGUKICAgICAgY2hvaWNl
IGZpcnN0LCBzaWduYWxpbmcgY2lwaGVyIHN1aXRlIHZhbHVlcyB3aWxsIGdlbmVyYWxseSBhcHBl
YXIKICAgICAgYWZ0ZXIgYWxsIGNpcGhlciBzdWl0ZXMgdGhhdCB0aGUgY2xpZW50IGFjdHVhbGx5
IGludGVuZHMgdG8KICAgICAgbmVnb3RpYXRlLikKCgoKICAgbyAgQXMgYW4gZXhjZXB0aW9uIHRv
IHRoZSBhYm92ZSwgd2hlbiBhIGNsaWVudCBpbnRlbmRzIHRvIHJlc3VtZSBhCiAgICAgIHNlc3Np
b24gYW5kIHNldHMgQ2xpZW50SGVsbG8uY2xpZW50X3ZlcnNpb24gdG8gdGhlIHByb3RvY29sCiAg
ICAgIHZlcnNpb24gbmVnb3RpYXRlZCBmb3IgdGhhdCBzZXNzaW9uLCBpdCBNVVNUIE5PVCBpbmNs
dWRlCiAgICAgIFRMU19GQUxMQkFDS19TQ1NWIGluIENsaWVudEhlbGxvLmNpcGhlcl9zdWl0ZXMu
ICAoSW4gdGhpcyBjYXNlLCBpdAogICAgICBpcyBhc3N1bWVkIHRoYXQgdGhlIGNsaWVudCBhbHJl
YWR5IGtub3dzIHRoZSBoaWdoZXN0IHByb3RvY29sCiAgICAgIHZlcnNpb24gc3VwcG9ydGVkIGJ5
IHRoZSBzZXJ2ZXI6IHNlZSBbUkZDNTI0Nl0sIEFwcGVuZGl4IEUuMS4pCgogICBvICBJZiBhIGNs
aWVudCBzZXRzIENsaWVudEhlbGxvLmNsaWVudF92ZXJzaW9uIHRvIGl0cyBoaWdoZXN0CiAgICAg
IHN1cHBvcnRlZCBwcm90b2NvbCB2ZXJzaW9uLCBpdCBNVVNUIE5PVCBpbmNsdWRlIFRMU19GQUxM
QkFDS19TQ1NWCiAgICAgIGluIENsaWVudEhlbGxvLmNpcGhlcl9zdWl0ZXMuCgogICAoQSBwcm90
b2NvbCB2ZXJzaW9uIGlzIHN1cHBvcnRlZCBieSB0aGUgY2xpZW50IGlmIHRoZSBjbGllbnQgbm9y
bWFsbHkKICAgYXR0ZW1wdHMgdG8gdXNlIGl0IGluIGhhbmRzaGFrZXMuICBJZiBhIHBhcnRpY3Vs
YXIgcHJvdG9jb2wgdmVyc2lvbgogICBpcyBpbXBsZW1lbnRlZCBidXQgY29tcGxldGVseSBkaXNh
YmxlZCBieSBjbGllbnQgc2V0dGluZ3MsIGl0IGlzIG5vdAogICBjb25zaWRlcmVkIHN1cHBvcnRl
ZC4gIEZvciBleGFtcGxlLCBpZiB0aGUgaW1wbGVtZW50YXRpb24ncyBoaWdoZXN0CiAgIHByb3Rv
Y29sIHZlcnNpb24gaXMgVExTIDEuMiBidXQgdGhlIHVzZXIgaGFzIGRpc2FibGVkIHRoaXMgdmVy
c2lvbiwgYQogICBUTFMgMS4xIGhhbmRzaGFrZSBpcyBleHBlY3RlZCBhbmQgZG9lcyBub3Qgd2Fy
cmFudCBzZW5kaW5nCiAgIFRMU19GQUxMQkFDS19TQ1NWLikKCiAgIElmIGEgY2xpZW50IGtlZXBz
IHRyYWNrIG9mIHRoZSBoaWdoZXN0IHByb3RvY29sIHZlcnNpb24gYXBwYXJlbnRseQogICBzdXBw
b3J0ZWQgYnkgYSBwYXJ0aWN1bGFyIHNlcnZlciBmb3IgdXNlIGluCgoKCk1vZWxsZXIgJiBMYW5n
bGV5ICAgICAgICAgIEV4cGlyZXMgTWF5IDIsIDIwMTUgICAgICAgICAgICAgICAgICBbUGFnZSA0
XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBUTFMgRmFsbGJhY2sgU0NTViAgICAgICAg
ICAgICAgIE9jdG9iZXIgMjAxNAoKCiAgIENsaWVudEhlbGxvLmNsaWVudF92ZXJzaW9uIGxhdGVy
LCB0aGVuIGlmIHRoZSBjbGllbnQgcmVjZWl2ZXMgYW4KICAgaW5hcHByb3ByaWF0ZV9mYWxsYmFj
ayBhbGVydCBmcm9tIHRoYXQgc2VydmVyLCBpdCBNVVNUIGNsZWFyIHRoZQogICBtZW1vcml6ZWQg
aGlnaGVzdCBzdXBwb3J0ZWQgcHJvdG9jb2wgdmVyc2lvbi4gIChXaXRob3V0IHRoZSBhbGVydCwg
aXQKICAgaXMgYSBnb29kIGlkZWEgLS0gYnV0IG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoaXMg
ZG9jdW1lbnQgLS0gZm9yCiAgIGNsaWVudHMgdG8gY2xlYXIgdGhhdCBzdGF0ZSBhZnRlciBhIHRp
bWUtb3V0LCBzaW5jZSB0aGUgc2VydmVyJ3MKICAgaGlnaGVzdCBwcm90b2NvbCB2ZXJzaW9uIGNv
dWxkIGNoYW5nZSBvdmVyIHRpbWUuKQoKICAgRm9yIGNsaWVudHMgdGhhdCB1c2UgY2xpZW50LXNp
ZGUgVExTIEZhbHNlIFN0YXJ0IFtmYWxzZS1zdGFydF0sIGl0IGlzCiAgIGltcG9ydGFudCB0byBu
b3RlIHRoYXQgdGhlIFRMU19GQUxMQkFDS19TQ1NWIG1lY2hhbnNpbSBjYW5ub3QgcHJvdGVjdAog
ICB0aGUgZmlyc3Qgcm91bmQgb2YgYXBwbGljYXRpb24gZGF0YSBzZW50IGJ5IHRoZSBjbGllbnQ6
IHJlZmVyIHRvIHRoZQogICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBpbiBbZmFsc2Utc3RhcnRd
LCBTZWN0aW9uIDYuCgo1LiAgT3BlcmF0aW9uYWwgQ29uc2lkZXJhdGlvbnMKCiAgIFVwZGF0aW5n
IGxlZ2FjeSBzZXJ2ZXIgY2x1c3RlcnMgdG8gc2ltdWx0YW5lb3VzbHkgYWRkIHN1cHBvcnQgZm9y
CiAgIG5ld2VyIHByb3RvY29sIHZlcnNpb25zIGFuZCBzdXBwb3J0IGZvciBUTFNfRkFMTEJBQ0tf
U0NTViBjYW4gaGF2ZQogICBjb21wbGljYXRpb25zLCBpZiB0aGUgbGVnYWN5IHNlcnZlciBpbXBs
ZW1lbnRhdGlvbiBpcyBub3QgInZlcnNpb24tCiAgIHRvbGVyYW50IiAoY2Fubm90IHByb3Blcmx5
IGhhbmRsZSBDbGllbnQgSGVsbG8gbWVzc2FnZXMgZm9yIG5ld2VyCiAgIHByb3RvY29sIHZlcnNp
b25zKTogZmFsbGJhY2sgcmV0cmllcyByZXF1aXJlZCBmb3IgaW50ZXJvcGVyYWJpbGl0eQogICB3
aXRoIG9sZCBzZXJ2ZXIgbm9kZXMgbWlnaHQgYmUgcmVqZWN0ZWQgYnkgdXBkYXRlZCBzZXJ2ZXIg
bm9kZXMuCgogICBVcGRhdGluZyB0aGUgc2VydmVyIGNsdXN0ZXIgaW4gdHdvIGNvbnNlY3V0aXZl
IHN0ZXBzIG1ha2VzIHRoaXMgc2FmZToKICAgZmlyc3QsIHVwZGF0ZSB0aGUgc2VydmVyIHNvZnR3
YXJlIGJ1dCBsZWF2ZSB0aGUgaGlnaGVzdCBzdXBwb3J0ZWQKICAgdmVyc2lvbiB1bmNoYW5nZWQg
KGJ5IGRpc2FibGluZyBuZXdlciB2ZXJzaW9ucyBpbiBzZXJ2ZXIgc2V0dGluZ3MpOwogICBhZnRl
ciB0aGF0IHN0ZXAgaGFzIGNvbmNsdWRlZCwgY2hhbmdlIHNlcnZlciBzZXR0aW5ncyB0byBhbGxv
dyBuZXcKICAgcHJvdG9jb2wgdmVyc2lvbnMuCgo2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMK
CiAgIFNlY3Rpb24gNCBkb2VzIG5vdCByZXF1aXJlIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgdG8g
c2VuZAogICBUTFNfRkFMTEJBQ0tfU0NTViBpbiBhbnkgcGFydGljdWxhciBjYXNlLCBpdCBtZXJl
bHkgcmVjb21tZW5kcyBpdDsKICAgYmVoYXZpb3IgY2FuIGJlIGFkYXB0ZWQgYWNjb3JkaW5nIHRv
IHRoZSBjbGllbnQncyBzZWN1cml0eSBuZWVkcy4KICAgRm9yIGV4YW1wbGUsIGR1cmluZyB0aGUg
aW5pdGlhbCBkZXBsb3ltZW50IG9mIGEgbmV3IHByb3RvY29sIHZlcnNpb24KICAgKHdoZW4gc29t
ZSBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zIG1heSBoYXZlIHRvIGJlIGV4cGVjdGVkKSwKICAg
c21vb3RobHkgZmFsbGluZyBiYWNrIHRvIHRoZSBwcmV2aW91cyBwcm90b2NvbCB2ZXJzaW9uIGlu
IGNhc2Ugb2YKICAgcHJvYmxlbXMgbWF5IGJlIHByZWZlcnJhYmxlIHRvIHBvdGVudGlhbGx5IG5v
dCBiZWluZyBhYmxlIHRvIGNvbm5lY3QKICAgYXQgYWxsOiBzbyBUTFNfRkFMTEJBQ0tfU0NTViBj
b3VsZCBiZSBvbWl0dGVkIGZvciB0aGlzIHBhcnRpY3VsYXIKICAgcHJvdG9jb2wgZG93bmdyYWRl
IHN0ZXAuCgogICBIb3dldmVyLCBpdCBpcyBzdHJvbmdseSByZWNvbW1lbmRlZCB0byBzZW5kIFRM
U19GQUxMQkFDS19TQ1NWIHdoZW4KICAgZG93bmdyYWRpbmcgdG8gU1NMIDMuMCBhcyB0aGUgQ0JD
IGNpcGhlciBzdWl0ZXMgaW4gU1NMIDMuMCBoYXZlCiAgIHdlYWtuZXNzZXMgdGhhdCBjYW5ub3Qg
YmUgYWRkcmVzc2VkIGJ5IGltcGxlbWVudGF0aW9uIHdvcmthcm91bmRzCiAgIGxpa2UgdGhlIHJl
bWFpbmluZyB3ZWFrbmVzc2VzIGluIGxhdGVyIChUTFMpIHByb3RvY29sIHZlcnNpb25zLgoKCgoK
CgoKCk1vZWxsZXIgJiBMYW5nbGV5ICAgICAgICAgIEV4cGlyZXMgTWF5IDIsIDIwMTUgICAgICAg
ICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBUTFMgRmFs
bGJhY2sgU0NTViAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxNAoKCjcuICBJQU5BIENvbnNpZGVy
YXRpb25zCgogICBbWyBOT1RFIElOIERSQUZUOiBUaGUgcmVxdWVzdGVkIHJlZ2lzdHJ5IGFsbG9j
YXRpb24gcmVxdWlyZXMKICAgU3RhbmRhcmRzIEFjdGlvbiwgaS5lLiwgd2lsbCBvbmx5IGJlIG9m
ZmljaWFsIHdpdGggdGhlIElFU0cncwogICBTdGFuZGFyZHMgVHJhY2sgUkZDIGFwcHJvdmFsLiAg
U2luY2UgdGhpcyBkb2N1bWVudCBpcyBjdXJyZW50bHkgYW4KICAgSW50ZXJuZXQtRHJhZnQsIElB
TkEgc28gZmFyIGhhcyBpbiBmYWN0IG5vdCBhZGRlZCB0aGUgY2lwaGVyIHN1aXRlCiAgIG51bWJl
ciB0byB0aGUgcmVnaXN0cnkuIF1dCgogICBJQU5BIGhhcyBhZGRlZCBUTFMgY2lwaGVyIHN1aXRl
IG51bWJlciAweDU2LDB4MDAgd2l0aCBuYW1lCiAgIFRMU19GQUxMQkFDS19TQ1NWIHRvIHRoZSBU
TFMgQ2lwaGVyIFN1aXRlIHJlZ2lzdHJ5LgoKOC4gIFJlZmVyZW5jZXMKCjguMS4gIE5vcm1hdGl2
ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1
c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIs
IEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICBbUkZDMjI0Nl0gIERpZXJrcywgVC4g
YW5kIEMuIEFsbGVuLCAiVGhlIFRMUyBQcm90b2NvbCBWZXJzaW9uIDEuMCIsCiAgICAgICAgICAg
ICAgUkZDIDIyNDYsIEphbnVhcnkgMTk5OS4KCiAgIFtSRkM0MzQ2XSAgRGllcmtzLCBULiBhbmQg
RS4gUmVzY29ybGEsICJUaGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5CiAgICAgICAgICAgICAg
KFRMUykgUHJvdG9jb2wgVmVyc2lvbiAxLjEiLCBSRkMgNDM0NiwgQXByaWwgMjAwNi4KCiAgIFtS
RkM1MjQ2XSAgRGllcmtzLCBULiBhbmQgRS4gUmVzY29ybGEsICJUaGUgVHJhbnNwb3J0IExheWVy
IFNlY3VyaXR5CiAgICAgICAgICAgICAgKFRMUykgUHJvdG9jb2wgVmVyc2lvbiAxLjIiLCBSRkMg
NTI0NiwgQXVndXN0IDIwMDguCgo4LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZD
NjEwMV0gIEZyZWllciwgQS4sIEthcmx0b24sIFAuLCBhbmQgUC4gS29jaGVyLCAiVGhlIFNlY3Vy
ZQogICAgICAgICAgICAgIFNvY2tldHMgTGF5ZXIgKFNTTCkgUHJvdG9jb2wgVmVyc2lvbiAzLjAi
LCBSRkMgNjEwMSwKICAgICAgICAgICAgICBBdWd1c3QgMjAxMS4KCiAgIFtmYWxzZS1zdGFydF0K
ICAgICAgICAgICAgICBMYW5nbGV5LCBBLiwgTW9kYWR1Z3UsIE4uLCBhbmQgQi4gTW9lbGxlciwg
IlRyYW5zcG9ydAogICAgICAgICAgICAgIExheWVyIFNlY3VyaXR5IChUTFMpIEZhbHNlIFN0YXJ0
IiwgV29yayBpbiBQcm9ncmVzcywKICAgICAgICAgICAgICBkcmFmdC1ibW9lbGxlci10bHMtZmFs
c2VzdGFydC0wMSwgTm92ZW1iZXIgMjAxNC4KCkFwcGVuZGl4IEEuICBBY2tub3dsZWRnZW1lbnRz
CgogICBUaGlzIHNwZWNpZmljYXRpb24gd2FzIGluc3BpcmVkIGJ5IGFuIGVhcmxpZXIgcHJvcG9z
YWwgYnkgRXJpYwogICBSZXNjb3JsYS4gIFdlIGFsc28gdGhhbmsgTWFydGluIFRob21zb24sIEJy
aWFuIFNtaXRoLCBhbmQgb3RoZXJzIGluCiAgIHRoZSBUTFMgV29ya2luZyBHcm91cCBmb3IgdGhl
aXIgZmVlZGJhY2sgYW5kIHN1Z2dlc3Rpb25zLgoKCgoKCgoKCk1vZWxsZXIgJiBMYW5nbGV5ICAg
ICAgICAgIEV4cGlyZXMgTWF5IDIsIDIwMTUgICAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCklu
dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBUTFMgRmFsbGJhY2sgU0NTViAgICAgICAgICAgICAg
IE9jdG9iZXIgMjAxNAoKCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAgQm9kbyBNb2VsbGVyCiAgIEdv
b2dsZSBTd2l0emVybGFuZCBHbWJICiAgIEJyYW5kc2NoZW5rZXN0cmFzc2UgMTEwCiAgIFp1cmlj
aCAgODAwMgogICBTd2l0emVybGFuZAoKICAgRW1haWw6IGJtb2VsbGVyQGFjbS5vcmcKCgogICBB
ZGFtIExhbmdsZXkKICAgR29vZ2xlIEluYy4KICAgMzQ1IFNwZWFyIFN0CiAgIFNhbiBGcmFuY2lz
Y28sIENBICA5NDEwNQogICBVU0EKCiAgIEVtYWlsOiBhZ2xAZ29vZ2xlLmNvbQoKCgoKCgoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpNb2VsbGVyICYgTGFuZ2xleSAgICAgICAgICBFeHBpcmVz
IE1heSAyLCAyMDE1ICAgICAgICAgICAgICAgICAgW1BhZ2UgN10K
--089e0160c47824197b05068f6680
Content-Type: text/plain; charset=US-ASCII; 
	name="DRAFT-draft-bmoeller-tls-falsestart-01.txt"
Content-Disposition: attachment; 
	filename="DRAFT-draft-bmoeller-tls-falsestart-01.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i1uosevt1

CgoKClRMUyBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgQS4gTGFuZ2xleQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHb29nbGUKSW50ZW5kZWQgc3RhdHVzOiBFeHBl
cmltZW50YWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE4uIE1vZGFkdWd1CkV4cGly
ZXM6IE1heSAyLCAyMDE1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJ
bmRlcGVuZGVudAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIEIuIE1vZWxsZXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR29vZ2xlCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT2N0b2JlciAyOSwgMjAx
NAoKCiAgICAgICAgICAgICAgIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBGYWxzZSBT
dGFydAogICAgICAgICAgICAgICAgIERSQUZULWRyYWZ0LWJtb2VsbGVyLXRscy1mYWxzZXN0YXJ0
LTAxCgpBYnN0cmFjdAoKICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gb3B0aW9uYWwgYmVo
YXZpb3Igb2YgVExTIGltcGxlbWVudGF0aW9ucywKICAgZHViYmVkIEZhbHNlIFN0YXJ0LiAgSXQg
YWZmZWN0cyBvbmx5IHByb3RvY29sIHRpbWluZywgbm90IG9uLXRoZS13aXJlCiAgIHByb3RvY29s
IGRhdGEsIGFuZCBjYW4gYmUgaW1wbGVtZW50ZWQgdW5pbGF0ZXJhbGx5LiAgVGhlIFRMUyBGYWxz
ZQogICBTdGFydCBmZWF0dXJlIGxlYWRzIHRvIGEgbGF0ZW5jeSByZWR1Y3Rpb24gb2Ygb25lIHJv
dW5kIHRyaXAgZm9yCiAgIGNlcnRhaW4gaGFuZHNoYWtlcy4KClN0YXR1cyBvZiBUaGlzIE1lbW8K
CiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ug
d2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0
LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5n
CiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBk
aXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBs
aXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm
dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkg
YmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQg
YW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMg
YXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3
b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g
TWF5IDIsIDIwMTUuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTQgSUVU
RiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0
aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3Qg
dG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRp
bmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2Ut
aW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9j
dW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRo
ZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAg
dG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRv
Y3VtZW50IG11c3QKCgoKTGFuZ2xleSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBNYXkgMiwg
MjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg
ICAgICBUTFMgRmFsc2UgU3RhcnQgICAgICAgICAgICAgICAgT2N0b2JlciAyMDE0CgoKICAgaW5j
bHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g
NC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0
aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vu
c2UuCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIFJlcXVpcmVtZW50cyBOb3RhdGlvbiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgIDIuICBJbnRyb2R1Y3Rp
b24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMgog
ICAzLiAgRmFsc2UgU3RhcnQgQ29tcGF0aWJpbGl0eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAgIDUKICAgNC4gIENsaWVudC1zaWRlIEZhbHNlIFN0YXJ0IC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgIDUuICBTZXJ2ZXItc2lkZSBGYWxzZSBT
dGFydCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICA2LiAgU2Vj
dXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAgIDcKICAgICA2LjEuICBTeW1tZXRyaWMgQ2lwaGVyICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gICA3CiAgICAgNi4yLiAgUHJvdG9jb2wgVmVyc2lvbiAgLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOAogICAgIDYuMy4gIEtleSBFeGNo
YW5nZSBhbmQgQ2xpZW50IENlcnRpZmljYXRlIFR5cGUgIC4gLiAuIC4gLiAuIC4gLiAgIDgKICAg
Ny4gIEFja25vd2xlZGdtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gICA5CiAgIDguICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQogICA5LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkKICAgICA5LjEuICBO
b3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
ICA5CiAgICAgOS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuICAxMAogICBBcHBlbmRpeCBBLiAgSW1wbGVtZW50YXRpb24gTm90ZXMg
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTAKICAgQXV0aG9ycycgQWRkcmVzc2Vz
ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwCgoxLiAg
UmVxdWlyZW1lbnRzIE5vdGF0aW9uCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9U
IiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxE
IE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRv
Y3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkgW1JG
QzIxMTldLgoKMi4gIEludHJvZHVjdGlvbgoKICAgQSBmdWxsIFRMUyBoYW5kc2hha2UgYXMgc3Bl
Y2lmaWVkIGluIFtSRkM1MjQ2XSByZXF1aXJlcyB0d28gZnVsbAogICBwcm90b2NvbCByb3VuZHMg
KGZvdXIgZmxpZ2h0cykgYmVmb3JlIHRoZSBoYW5kc2hha2UgaXMgY29tcGxldGUgYW5kCiAgIHRo
ZSBwcm90b2NvbCBwYXJ0aWVzIG1heSBiZWdpbiB0byBzZW5kIGFwcGxpY2F0aW9uIGRhdGEuICBU
aHVzLCB1c2luZwogICBUTFMgY2FuIGFkZCBhIGxhdGVuY3kgcGVuYWx0eSBvZiB0d28gbmV0d29y
ayByb3VuZC10cmlwIHRpbWVzIGZvcgogICBhcHBsaWNhdGlvbiBwcm90b2NvbHMgaW4gd2hpY2gg
dGhlIGNsaWVudCBzZW5kcyBkYXRhIGZpcnN0LCBzdWNoIGFzCiAgIEhUVFAgW1JGQzI2MTZdLiAg
QW4gYWJicmV2aWF0ZWQgaGFuZHNoYWtlIChyZXN1bWluZyBhbiBlYXJsaWVyIFRMUwogICBzZXNz
aW9uKSBpcyBjb21wbGV0ZSBhZnRlciB0aHJlZSBmbGlnaHRzLCB0aHVzIGFkZGluZyBqdXN0IG9u
ZSByb3VuZC0KICAgdHJpcCB0aW1lIGlmIHRoZSBjbGllbnQgc2VuZHMgYXBwbGljYXRpb24gZGF0
YSBmaXJzdC4KCgoKCgoKCgoKCgoKTGFuZ2xleSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBN
YXkgMiwgMjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAg
ICAgICAgICAgICBUTFMgRmFsc2UgU3RhcnQgICAgICAgICAgICAgICAgT2N0b2JlciAyMDE0CgoK
ICAgICAgQ2xpZW50ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBTZXJ2ZXIKCiAgICAgIENsaWVudEhlbGxvICAgICAgICAgICAgICAgICAgLS0tLS0tLS0+CiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlcnZl
ckhlbGxvCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgQ2VydGlmaWNhdGUqCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgU2VydmVyS2V5RXhjaGFuZ2UqCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZVJlcXVlc3QqCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPC0tLS0tLS0tICAgICAgU2VydmVySGVsbG9Eb25lCiAgICAgIENlcnRpZmlj
YXRlKgogICAgICBDbGllbnRLZXlFeGNoYW5nZQogICAgICBDZXJ0aWZpY2F0ZVZlcmlmeSoKICAg
ICAgW0NoYW5nZUNpcGhlclNwZWNdCiAgICAgIEZpbmlzaGVkICAgICAgICAgICAgICAgICAgICAg
LS0tLS0tLS0+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
W0NoYW5nZUNpcGhlclNwZWNdCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0t
LS0tLS0tICAgICAgICAgICAgIEZpbmlzaGVkCiAgICAgIEFwcGxpY2F0aW9uIERhdGEgICAgICAg
ICAgICAgPC0tLS0tLS0+ICAgICBBcHBsaWNhdGlvbiBEYXRhCgogICAgICAgIEZpZ3VyZSAxIFtS
RkM1MjQ2XS4gIE1lc3NhZ2UgZmxvdyBmb3IgYSBmdWxsIGhhbmRzaGFrZQoKCgoKCgoKCgoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgpMYW5nbGV5LCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIE1h
eSAyLCAyMDE1ICAgICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAg
ICAgICAgICAgIFRMUyBGYWxzZSBTdGFydCAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTQKCgog
ICAgICBDbGllbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBTZXJ2ZXIKCiAgICAgIENsaWVudEhlbGxvICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tPgog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2Vy
dmVySGVsbG8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
W0NoYW5nZUNpcGhlclNwZWNdCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwt
LS0tLS0tLSAgICAgICAgICAgICBGaW5pc2hlZAogICAgICBbQ2hhbmdlQ2lwaGVyU3BlY10KICAg
ICAgRmluaXNoZWQgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0+CiAgICAgIEFwcGxpY2F0
aW9uIERhdGEgICAgICAgICAgICAgIDwtLS0tLS0tPiAgICAgQXBwbGljYXRpb24gRGF0YQoKICAg
ICBGaWd1cmUgMiBbUkZDNTI0Nl0uICBNZXNzYWdlIGZsb3cgZm9yIGFuIGFiYnJldmlhdGVkIGhh
bmRzaGFrZQoKICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSB0ZWNobmlxdWUgdGhhdCBhbGxl
dmlhdGVzIHRoZSBsYXRlbmN5CiAgIGJ1cmRlbiBpbXBvc2VkIGJ5IFRMUzogdGhlIFRMUyBGYWxz
ZSBTdGFydC4gIElmIGNlcnRhaW4gY29uZGl0aW9ucwogICBhcmUgbWV0LCBhcHBsaWNhdGlvbiBk
YXRhIGNhbiBiZSBzZW50IHdoZW4gdGhlIGhhbmRzaGFrZSBpcyBvbmx5CiAgIHBhcnRpYWxseSBj
b21wbGV0ZSAtLSBpLmUuLCB3aGVuIHRoZSBzZW5kZXIgaGFzIHNlbnQgaXRzIG93bgogICAiQ2hh
bmdlQ2lwaGVyU3BlYyIgYW5kICJGaW5pc2hlZCIgbWVzc2FnZXMgKHRodXMgaGF2aW5nIHVwZGF0
ZWQgaXRzCiAgIFRMUyBSZWNvcmQgUHJvdG9jb2wgd3JpdGUgc3RhdGUgYXMgbmVnb3RpYXRlZCBp
biB0aGUgaGFuZHNoYWtlKSwgYnV0CiAgIGhhcyB5ZXQgdG8gcmVjZWl2ZSB0aGUgb3RoZXIgc2lk
ZSdzICJDaGFuZ2VDaXBoZXJTcGVjIiBhbmQgIkZpbmlzaGVkIgogICBtZXNzYWdlcy4gIChCeSBz
ZWN0aW9uIDcuNC45IG9mIFtSRkM1MjQ2XSwgZWFjaCBwYXJ0eSB3b3VsZCBoYXZlIHRvCiAgIGRl
bGF5IHNlbmRpbmcgYXBwbGljYXRpb24gZGF0YSB1bnRpbCBpdCBoYXMgcmVjZWl2ZWQgYW5kIHZh
bGlkYXRlZAogICB0aGUgb3RoZXIgc2lkZSdzICJGaW5pc2hlZCIgbWVzc2FnZS4pICBUaGlzIGFj
aGlldmVzIGFuIGltcHJvdmVtZW50CiAgIG9mIG9uZSByb3VuZC10cmlwIHRpbWUKCiAgIG8gIGZv
ciBmdWxsIGhhbmRzaGFrZXMgaWYgdGhlIGNsaWVudCBzZW5kcyBhcHBsaWNhdGlvbiBkYXRhIGZp
cnN0LAoKICAgbyAgZm9yIGFiYnJldmlhdGVkIGhhbmRzaGFrZXMgaWYgdGhlIHNlcnZlciBzZW5k
cyBhcHBsaWNhdGlvbiBkYXRhCiAgICAgIGZpcnN0LgoKICAgQWNjb3JkaW5nbHksIHRoZSBsYXRl
bmN5IHBlbmFsdHkgZm9yIHVzaW5nIFRMUyB3aXRoIEhUVFAgY2FuIGJlIGtlcHQKICAgYXQgb25l
IHJvdW5kLXRyaXAgdGltZSByZWdhcmRsZXNzIG9mIHdoZXRoZXIgYSBmdWxsIGhhbmRzaGFrZSBv
ciBhbgogICBhYmJyZXZpYXRlZCBoYW5kc2hha2UgdGFrZXMgcGxhY2UuCgogICBJbiBhIEZhbHNl
IFN0YXJ0LCB3aGVuIGEgcGFydHkgc2VuZHMgYXBwbGljYXRpb24gZGF0YSBiZWZvcmUgaXQgaGFz
CiAgIHJlY2VpdmVkIGFuZCB2ZXJpZmllZCB0aGUgb3RoZXIgcGFydHkncyAiRmluaXNoZWQiIG1l
c3NhZ2UsIHRoZXJlIGFyZQogICB0d28gcG9zc2libGUgb3V0Y29tZXM6CgogICBvICBUaGUgaGFu
ZHNoYWtlIGNvbXBsZXRlcyBzdWNjZXNzZnVsbHk6IE9uY2UgYm90aCAiRmluaXNoZWQiCiAgICAg
IG1lc3NhZ2VzIGhhdmUgYmVlbiByZWNlaXZlZCBhbmQgdmVyaWZpZWQsIHRoaXMgcmV0cm9hY3Rp
dmVseQogICAgICB2YWxpZGF0ZXMgdGhlIGhhbmRzaGFrZS4gIEluIHRoaXMgY2FzZSwgdGhlIHRy
YW5zY3JpcHQgb2YgcHJvdG9jb2wKICAgICAgZGF0YSBjYXJyaWVkIG92ZXIgdGhlIHRyYW5zcG9y
dCB1bmRlcmx5aW5nIFRMUyB3aWxsIGxvb2sgYXMgdXN1YWwsCiAgICAgIGFwYXJ0IGZyb20gdGhl
IGRpZmZlcmVudCB0aW1pbmcuCgogICBvICBUaGUgaGFuZHNoYWtlIGZhaWxzOiBJZiBhIHBhcnR5
IGRvZXMgbm90IHJlY2VpdmUgdGhlIG90aGVyIHNpZGUncwogICAgICAiRmluaXNoZWQiIG1lc3Nh
Z2UsIG9yIGlmIHRoZSAiRmluaXNoZWQiIG1lc3NhZ2UncyBjb250ZW50cyBhcmUKICAgICAgbm90
IGNvcnJlY3QsIHRoZSBoYW5kc2hha2UgbmV2ZXIgZ2V0cyB2YWxpZGF0ZWQuICBUaGlzIG1lYW5z
IHRoYXQKICAgICAgYW4gYXR0YWNrZXIgbWF5IGhhdmUgcmVtb3ZlZCwgY2hhbmdlZCwgb3IgaW5q
ZWN0ZWQgaGFuZHNoYWtlCgoKCgpMYW5nbGV5LCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIE1h
eSAyLCAyMDE1ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAg
ICAgICAgICAgIFRMUyBGYWxzZSBTdGFydCAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTQKCgog
ICAgICBtZXNzYWdlcy4gIEluIHRoaXMgY2FzZSwgZGF0YSBoYXMgYmVlbiBzZW50IG92ZXIgdGhl
IHVuZGVybHlpbmcKICAgICAgdHJhbnNwb3J0IHRoYXQgd291bGQgbm90IGhhdmUgYmVlbiBzZW50
IHdpdGhvdXQgdGhlIEZhbHNlIFN0YXJ0LgoKICAgVGhlIGxhdHRlciBzY2VuYXJpbyBtYWtlcyBp
dCBuZWNlc3NhcnkgdG8gcmVzdHJpY3Qgd2hlbiBhIEZhbHNlIFN0YXJ0CiAgIGlzIGFsbG93ZWQs
IGFzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LiAgU2VjdGlvbiAzIGNvbnNpZGVycyBiYXNp
YwogICByZXF1aXJlbWVudHMgZm9yIHVzaW5nIEZhbHNlIFN0YXJ0LiAgU2VjdGlvbiA0IGFuZCBT
ZWN0aW9uIDUgc3BlY2lmeQogICB0aGUgYmVoYXZpb3IgZm9yIGNsaWVudHMgYW5kIHNlcnZlcnMs
IHJlc3BlY3RpdmVseSwgcmVmZXJyaW5nIHRvCiAgIGltcG9ydGFudCBzZWN1cml0eSBjb25zaWRl
cmF0aW9ucyBpbiBTZWN0aW9uIDYuCgozLiAgRmFsc2UgU3RhcnQgQ29tcGF0aWJpbGl0eQoKICAg
VExTIEZhbHNlIFN0YXJ0IGFzIGRlc2NyaWJlZCBpbiBkZXRhaWwgaW4gdGhlIHN1YnNlcXVlbnQg
c2VjdGlvbnMsIGlmCiAgIGltcGxlbWVudGVkLCBpcyBhbiBvcHRpb25hbCBmZWF0dXJlLgoKICAg
QSBUTFMgaW1wbGVtZW50YXRpb24gKG5vdCBuZWNlc3NhcmlseSBvZmZlcmluZyB0aGUgRmFsc2Ug
U3RhcnQgb3B0aW9uCiAgIGl0c2VsZikgaXMgZGVmaW5lZCB0byBiZSAiRmFsc2UgU3RhcnQgY29t
cGF0aWJsZSIgaWYgaXQgdG9sZXJhdGVzCiAgIHJlY2VpdmluZyBUTFMgcmVjb3JkcyBvbiB0aGUg
dHJhbnNwb3J0IGNvbm5lY3Rpb24gZWFybHksIGJlZm9yZSB0aGUKICAgcHJvdG9jb2wgaGFzIHJl
YWNoZWQgdGhlIHN0YXRlIHRvIHByb2Nlc3MgdGhlc2UuICBUbyBzdWNjZXNzZnVsbHkgdXNlCiAg
IEZhbHNlIFN0YXJ0IGluIGEgVExTIGNvbm5lY3Rpb24sIHRoZSBvdGhlciBzaWRlIGhhcyB0byBi
ZSBGYWxzZSBTdGFydAogICBjb21wYXRpYmxlLiAgT3V0LW9mLWJhbmQga25vd2xlZGdlIHRoYXQg
dGhlIHBlZXIgaXMgRmFsc2UgU3RhcnQKICAgY29tcGF0aWJsZSBtYXkgYmUgYXZhaWxhYmxlLCBl
LmcuIGlmIHRoaXMgaXMgbWFuZGF0ZWQgYnkgc3BlY2lmaWMKICAgYXBwbGljYXRpb24gcHJvZmls
ZSBzdGFuZGFyZHMuICBBcyBkaXNjdXNzZWQgaW4gQXBwZW5kaXggQSwgdGhlCiAgIHJlcXVpcmVt
ZW50IGZvciBGYWxzZSBTdGFydCBjb21wYXRpYmlsaXR5IGRvZXMgbm90IHBvc2UgYSBoaW5kcmFu
Y2UKICAgaW4gcHJhY3RpY2UuCgo0LiAgQ2xpZW50LXNpZGUgRmFsc2UgU3RhcnQKCiAgIFRoaXMg
c2VjdGlvbiBzcGVjaWZpZXMgYSBjaGFuZ2UgdG8gdGhlIGJlaGF2aW9yIG9mIFRMUyBjbGllbnQK
ICAgaW1wbGVtZW50YXRpb25zIGluIGZ1bGwgVExTIGhhbmRzaGFrZXMuCgogICBXaGVuIHRoZSBj
bGllbnQgaGFzIHNlbnQgaXRzICJDaGFuZ2VDaXBoZXJTcGVjIiBhbmQgIkZpbmlzaGVkIgogICBt
ZXNzYWdlcywgaXRzIGRlZmF1bHQgYmVoYXZpb3IgZm9sbG93aW5nIFtSRkM1MjQ2XSBpcyB0byBu
b3Qgc2VuZAogICBhcHBsaWNhdGlvbiBkYXRhIHVudGlsIGl0IGhhcyByZWNlaXZlZCB0aGUgc2Vy
dmVyJ3MKICAgIkNoYW5nZUNpcGhlclNwZWMiIGFuZCAiRmluaXNoZWQiIG1lc3NhZ2VzLCB3aGlj
aCBjb21wbGV0ZXMgdGhlCiAgIGhhbmRzaGFrZS4gIFdpdGggdGhlIEZhbHNlIFN0YXJ0IHByb3Rv
Y29sIG1vZGlmaWNhdGlvbiwgdGhlIGNsaWVudAogICBNQVkgc2VuZCBhcHBsaWNhdGlvbiBkYXRh
IGVhcmxpZXIgKHVuZGVyIHRoZSBuZXcgQ2lwaGVyIFNwZWMpIGlmIGVhY2gKICAgb2YgdGhlIGZv
bGxvd2luZyBjb25kaXRpb25zIGlzIHNhdGlzZmllZDoKCiAgIG8gIFRoZSBhcHBsaWNhdGlvbiBs
YXllciBoYXMgcmVxdWVzdGVkIHRoZSBUTFMgRmFsc2UgU3RhcnQgb3B0aW9uLgoKICAgbyAgVGhl
IHN5bW1ldHJpYyBjaXBoZXIgZGVmaW5lZCBieSB0aGUgY2lwaGVyIHN1aXRlIG5lZ290aWF0ZWQg
aW4KICAgICAgdGhpcyBoYW5kc2hha2UgaGFzIGJlZW4gd2hpdGVsaXN0ZWQgZm9yIHVzZSB3aXRo
IEZhbHNlIFN0YXJ0CiAgICAgIGFjY29yZGluZyB0byB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlv
bnMgaW4gU2VjdGlvbiA2LjEuCgogICBvICBUaGUgcHJvdG9jb2wgdmVyc2lvbiBjaG9zZW4gYnkg
U2VydmVySGVsbG8uc2VydmVyX3ZlcnNpb24gaGFzIGJlZW4KICAgICAgd2hpdGVsaXN0ZWQgZm9y
IHVzZSB3aXRoIEZhbHNlIFN0YXJ0IGFjY29yZGluZyB0byB0aGUgU2VjdXJpdHkKICAgICAgQ29u
c2lkZXJhdGlvbnMgaW4gU2VjdGlvbiA2LjIuCgoKCgpMYW5nbGV5LCBldCBhbC4gICAgICAgICAg
ICBFeHBpcmVzIE1heSAyLCAyMDE1ICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5l
dC1EcmFmdCAgICAgICAgICAgICAgIFRMUyBGYWxzZSBTdGFydCAgICAgICAgICAgICAgICBPY3Rv
YmVyIDIwMTQKCgogICBvICBUaGUga2V5IGV4Y2hhbmdlIG1ldGhvZCBkZWZpbmVkIGJ5IHRoZSBj
aXBoZXIgc3VpdGUgbmVnb3RpYXRlZCBpbgogICAgICB0aGlzIGhhbmRzaGFrZSBoYXMgYmVlbiB3
aGl0ZWxpc3RlZCBmb3IgdXNlIHdpdGggRmFsc2UgU3RhcnQKICAgICAgYWNjb3JkaW5nIHRvIHRo
ZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBpbiBTZWN0aW9uIDYuMy4KCiAgIG8gIEluIHRoZSBj
YXNlIG9mIGEgaGFuZHNoYWtlIHdpdGggY2xpZW50IGF1dGhlbnRpY2F0aW9uLCB0aGUgY2xpZW50
CiAgICAgIGNlcnRpZmljYXRlIHR5cGUgaGFzIGJlZW4gd2hpdGVsaXN0ZWQgZm9yIHVzZSB3aXRo
IEZhbHNlIFN0YXJ0CiAgICAgIGFjY29yZGluZyB0byB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlv
bnMgaW4gU2VjdGlvbiA2LjMuCgogICBUaGUgcnVsZXMgZm9yIHJlY2VpdmluZyBhcHBsaWNhdGlv
biBkYXRhIGZyb20gdGhlIHNlcnZlciByZW1haW4KICAgdW5jaGFuZ2VkLgoKICAgTm90ZSB0aGF0
IHRoZSBUTFMgY2xpZW50IGNhbm5vdCBpbmZlciB0aGUgcHJlc2VuY2Ugb2YgYW4KICAgYXV0aGVu
dGljYXRlZCBzZXJ2ZXIgdW50aWwgYWxsIGhhbmRzaGFrZSBtZXNzYWdlcyBoYXZlIGJlZW4gcmVj
ZWl2ZWQuCiAgIFdpdGggRmFsc2UgU3RhcnQsIHVubGlrZSB3aXRoIHRoZSBkZWZhdWx0IGhhbmRz
aGFrZSBiZWhhdmlvciwKICAgYXBwbGljYXRpb25zIGFyZSBhYmxlIHRvIHNlbmQgZGF0YSBiZWZv
cmUgdGhpcyBwb2ludCBoYXMgYmVlbgogICByZWFjaGVkOiBmcm9tIGFuIGFwcGxpY2F0aW9uIHBv
aW50IG9mIHZpZXcsIGJlaW5nIGFibGUgdG8gc2VuZCBkYXRhCiAgIGRvZXMgbm90IGltcGx5IHRo
YXQgYW4gYXV0aGVudGljYXRlZCBwZWVyIGlzIHByZXNlbnQuICBBY2NvcmRpbmdseSwKICAgaXQg
aXMgcmVjb21tZW5kZWQgdGhhdCBUTFMgaW1wbGVtZW50YXRpb25zIGFsbG93IHRoZSBhcHBsaWNh
dGlvbgogICBsYXllciB0byBxdWVyeSB3aGV0aGVyIHRoZSBoYW5kc2hha2UgaGFzIGNvbXBsZXRl
ZC4KCjUuICBTZXJ2ZXItc2lkZSBGYWxzZSBTdGFydAoKICAgVGhpcyBzZWN0aW9uIHNwZWNpZmll
cyBhIGNoYW5nZSB0byB0aGUgYmVoYXZpb3Igb2YgVExTIHNlcnZlcgogICBpbXBsZW1lbnRhdGlv
bnMgaW4gYWJicmV2aWF0ZWQgVExTIGhhbmRzaGFrZXMuCgogICBXaGVuIHRoZSBzZXJ2ZXIgaGFz
IHNlbnQgaXRzICJDaGFuZ2VDaXBoZXJTcGVjIiBhbmQgIkZpbmlzaGVkIgogICBtZXNzYWdlcywg
aXRzIGRlZmF1bHQgYmVoYXZpb3IgZm9sbG93aW5nIFtSRkM1MjQ2XSBpcyBub3QgdG8gc2VuZAog
ICBhcHBsaWNhdGlvbiBkYXRhIHVudGlsIGl0IGhhcyByZWNlaXZlZCB0aGUgY2xpZW50J3MKICAg
IkNoYW5nZUNpcGhlclNwZWMiIGFuZCAiRmluaXNoZWQiIG1lc3NhZ2VzLCB3aGljaCBjb21wbGV0
ZXMgdGhlCiAgIGhhbmRzaGFrZS4gIFdpdGggdGhlIEZhbHNlIFN0YXJ0IHByb3RvY29sIG1vZGlm
aWNhdGlvbiwgdGhlIHNlcnZlcgogICBNQVkgc2VuZCBhcHBsaWNhdGlvbiBkYXRhIGVhcmxpZXIg
KHVuZGVyIHRoZSBuZXcgQ2lwaGVyIFNwZWMpIGlmIGVhY2gKICAgb2YgdGhlIGZvbGxvd2luZyBj
b25kaXRpb25zIGlzIHNhdGlzZmllZDoKCiAgIG8gIFRoZSBhcHBsaWNhdGlvbiBsYXllciBoYXMg
cmVxdWVzdGVkIHRoZSBUTFMgRmFsc2UgU3RhcnQgb3B0aW9uLgoKICAgbyAgVGhlIHN5bW1ldHJp
YyBjaXBoZXIgZGVmaW5lZCBieSB0aGUgY2lwaGVyIHN1aXRlIG9mIHRoZSBzZXNzaW9uCiAgICAg
IGJlaW5nIHJlc3VtZWQgaGFzIGJlZW4gd2hpdGVsaXN0ZWQgZm9yIHVzZSB3aXRoIEZhbHNlIFN0
YXJ0CiAgICAgIGFjY29yZGluZyB0byB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgaW4gU2Vj
dGlvbiA2LjEuCgogICBUaGUgcnVsZXMgZm9yIHJlY2VpdmluZyBhcHBsaWNhdGlvbiBkYXRhIGZy
b20gdGhlIGNsaWVudCByZW1haW4KICAgdW5jaGFuZ2VkLgoKICAgTm90ZSB0aGF0IHRoZSBUTFMg
c2VydmVyIGNhbm5vdCBpbmZlciB0aGUgcHJlc2VuY2Ugb2YgYW4KICAgYXV0aGVudGljYXRlZCBj
bGllbnQgdW50aWwgYWxsIGhhbmRzaGFrZSBtZXNzYWdlcyBoYXZlIGJlZW4gcmVjZWl2ZWQuCiAg
IFdpdGggRmFsc2UgU3RhcnQsIHVubGlrZSB3aXRoIHRoZSBkZWZhdWx0IGhhbmRzaGFrZSBiZWhh
dmlvciwKICAgYXBwbGljYXRpb25zIGFyZSBhYmxlIHRvIHNlbmQgZGF0YSBiZWZvcmUgdGhpcyBw
b2ludCBoYXMgYmVlbgogICByZWFjaGVkOiBmcm9tIGFuIGFwcGxpY2F0aW9uIHBvaW50IG9mIHZp
ZXcsIGJlaW5nIGFibGUgdG8gc2VuZCBkYXRhCiAgIGRvZXMgbm90IGltcGx5IHRoYXQgYW4gYXV0
aGVudGljYXRlZCBwZWVyIGlzIHByZXNlbnQuICBBY2NvcmRpbmdseSwKCgoKTGFuZ2xleSwgZXQg
YWwuICAgICAgICAgICAgRXhwaXJlcyBNYXkgMiwgMjAxNSAgICAgICAgICAgICAgICAgIFtQYWdl
IDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBUTFMgRmFsc2UgU3RhcnQgICAgICAg
ICAgICAgICAgT2N0b2JlciAyMDE0CgoKICAgaXQgaXMgcmVjb21tZW5kZWQgdGhhdCBUTFMgaW1w
bGVtZW50YXRpb25zIGFsbG93IHRoZSBhcHBsaWNhdGlvbgogICBsYXllciB0byBxdWVyeSB3aGV0
aGVyIHRoZSBoYW5kc2hha2UgaGFzIGNvbXBsZXRlZC4KCjYuICBTZWN1cml0eSBDb25zaWRlcmF0
aW9ucwoKICAgSW4gYSBUTFMgaGFuZHNoYWtlLCB0aGUgIkZpbmlzaGVkIiBtZXNzYWdlcyBzZXJ2
ZSB0byB2YWxpZGF0ZSB0aGUKICAgZW50aXJlIGhhbmRzaGFrZS4gIFRoZXNlIG1lc3NhZ2VzIGFy
ZSBiYXNlZCBvbiBhIGhhc2ggb2YgdGhlCiAgIGhhbmRzaGFrZSBzbyBmYXIgcHJvY2Vzc2VkIGJ5
IGEgUFJGIGtleWVkIHdpdGggdGhlIG5ldyBtYXN0ZXIgc2VjcmV0CiAgIChzZXJ2aW5nIGFzIGEg
TUFDKSwgYW5kIGFyZSBhbHNvIHNlbnQgdW5kZXIgdGhlIG5ldyBDaXBoZXIgU3BlYyB3aXRoCiAg
IGl0cyBrZXllZCBNQUMsIHdoZXJlIHRoZSBNQUMga2V5IGFnYWluIGlzIGRlcml2ZWQgZnJvbSB0
aGUgbWFzdGVyCiAgIHNlY3JldC4gIFRoZSBwcm90b2NvbCBkZXNpZ24gcmVsaWVzIG9uIHRoZSBh
c3N1bXB0aW9uIHRoYXQgYW55IHNlcnZlcgogICBhbmQvb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9u
IGRvbmUgZHVyaW5nIHRoZSBoYW5kc2hha2UgY2FycmllcyBvdmVyCiAgIHRvIHRoaXMuICBXaGls
ZSBhbiBhdHRhY2tlciBjb3VsZCwgZm9yIGV4YW1wbGUsIGhhdmUgY2hhbmdlZCB0aGUKICAgY2lw
aGVyIHN1aXRlIGxpc3Qgc2VudCBieSB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIgYW5kIHRodXMK
ICAgaW5mbHVlbmNlZCBjaXBoZXIgc3VpdGUgc2VsZWN0aW9uIChwcmVzdW1hYmx5IHRvd2FyZHMg
YSBsZXNzIHNlY3VyZQogICBjaG9pY2UpIG9yIGNvdWxkIGhhdmUgbWFkZSBvdGhlciBtb2RpZmlj
YXRpb25zIHRvIGhhbmRzaGFrZSBtZXNzYWdlcwogICBpbiB0cmFuc21pc3Npb24sIHRoZSBhdHRh
Y2tlciB3b3VsZCBub3QgYmUgYWJsZSB0byByb3VuZCBvZmYgdGhlCiAgIG1vZGlmaWVkIGhhbmRz
aGFrZSB3aXRoIGEgdmFsaWQgIkZpbmlzaGVkIiBtZXNzYWdlOiBldmVyeSBUTFMgY2lwaGVyCiAg
IHN1aXRlIGlzIHByZXN1bWVkIHRvIGtleSB0aGUgUFJGIGFwcHJvcHJpYXRlbHkgdG8gZW5zdXJl
CiAgIHVuZm9yZ2VhYmlsaXR5LiAgT25jZSB0aGUgaGFuZHNoYWtlIGhhcyBiZWVuIHZhbGlkYXRl
ZCBieSB2ZXJpZnlpbmcKICAgdGhlICJGaW5pc2hlZCIgbWVzc2FnZXMsIHRoaXMgY29uZmlybXMg
dGhhdCB0aGUgaGFuZHNoYWtlIGhhcyBub3QKICAgYmVlbiB0YW1wZXJlZCB3aXRoLCB0aHVzIGJv
b3RzdHJhcHBpbmcgc2VjdXJlIGVuY3J5cHRpb24gKHVzaW5nCiAgIGFsZ29yaXRobXMgYXMgbmVn
b3RpYXRlZCkgZnJvbSBzZWN1cmUgYXV0aGVudGljYXRpb24uCgogICBVc2luZyBGYWxzZSBTdGFy
dCBpbnRlcmZlcmVzIHdpdGggdGhpcyBhcHByb2FjaCBvZiBib290c3RyYXBwaW5nCiAgIHNlY3Vy
ZSBlbmNyeXB0aW9uIGZyb20gc2VjdXJlIGF1dGhlbnRpY2F0aW9uLCBhcyBhcHBsaWNhdGlvbiBk
YXRhIG1heQogICBoYXZlIGFscmVhZHkgYmVlbiBzZW50IGJlZm9yZSAiRmluaXNoZWQiIHZhbGlk
YXRpb24gY29uZmlybXMgdGhhdCB0aGUKICAgaGFuZHNoYWtlIGhhcyBub3QgYmVlbiB0YW1wZXJl
ZCB3aXRoIC0tIHNvIHRoZXJlIGlzIGdlbmVyYWxseSBubyBob3BlCiAgIHRvIGJlIHN1cmUgdGhh
dCBjb21tdW5pY2F0aW9uIHdpdGggdGhlIGV4cGVjdGVkIHBlZXIgaXMgaW5kZWVkIHRha2luZwog
ICBwbGFjZSBkdXJpbmcgdGhlIEZhbHNlIFN0YXJ0LiAgSW5zdGVhZCwgdGhlIHNlY3VyaXR5IGdv
YWwgaXMgdG8KICAgZW5zdXJlIHRoYXQgaWYgYW55b25lIGF0IGFsbCBjYW4gZGVjcnlwdCB0aGUg
YXBwbGljYXRpb24gZGF0YSBzZW50IGluCiAgIGEgRmFsc2UgU3RhcnQsIHRoaXMgbXVzdCBiZSB0
aGUgbGVnaXRpbWF0ZSBwZWVyOiB3aGlsZSBhbiBhdHRhY2tlcgogICBjb3VsZCBiZSBpbmZsdWVu
Y2luZyB0aGUgaGFuZHNoYWtlIChyZXN0cmljdGluZyBjaXBoZXIgc3VpdGUKICAgc2VsZWN0aW9u
LCBtb2RpZnlpbmcga2V5IGV4Y2hhbmdlIG1lc3NhZ2VzLCBldGMuKSwgdGhlIGF0dGFja2VyCiAg
IHNob3VsZCBub3QgYmUgYWJsZSB0byBiZW5lZml0IGZyb20gdGhpcy4gIFRoZSBUTFMgcHJvdG9j
b2wgYWxyZWFkeQogICByZWxpZXMgb24gc3VjaCBhIHNlY3VyaXR5IHByb3BlcnR5IGZvciBhdXRo
ZW50aWNhdGlvbiAtLSB3aXRoIEZhbHNlCiAgIFN0YXJ0LCB0aGUgc2FtZSBpcyBuZWVkZWQgZm9y
IGVuY3J5cHRpb24uICBUaGlzIG1vdGl2YXRlcyB0aGUKICAgZm9sbG93aW5nIHJ1bGVzLgoKNi4x
LiAgU3ltbWV0cmljIENpcGhlcgoKICAgQ2xpZW50cyBhbmQgc2VydmVycyBNVVNUIE5PVCB1c2Ug
dGhlIEZhbHNlIFN0YXJ0IHByb3RvY29sCiAgIG1vZGlmaWNhdGlvbiBpbiBhIGhhbmRzaGFrZSB1
bmxlc3MgdGhlIGNpcGhlciBzdWl0ZSB1c2VzIGEgc3ltbWV0cmljCiAgIGNpcGhlciB0aGF0IGlz
IGNvbnNpZGVyZWQgY3J5cHRvZ3JhcGhpY2FsbHkgc3Ryb25nLgoKICAgSW1wbGVtZW50YXRpb25z
IG1heSBoYXZlIHRoZWlyIG93biBjbGFzc2lmaWNhdGlvbiBvZiBjaXBoZXJzIChhbmQgbWF5CiAg
IGFkZGl0aW9uYWxseSBhbGxvdyB0aGUgYXBwbGljYXRpb24gbGF5ZXIgdG8gcHJvdmlkZSBhCiAg
IGNsYXNzaWZpY2F0aW9uKSwgYnV0IGdlbmVyYWxseSBvbmx5IHN5bW1ldHJpYyBjaXBoZXJzIHdp
dGggYW4KCgoKTGFuZ2xleSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBNYXkgMiwgMjAxNSAg
ICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBU
TFMgRmFsc2UgU3RhcnQgICAgICAgICAgICAgICAgT2N0b2JlciAyMDE0CgoKICAgZWZmZWN0aXZl
IGtleSBsZW5ndGggb2YgMTI4IGJpdHMgb3IgbW9yZSBjYW4gYmUgY29uc2lkZXJlZCBzdHJvbmcu
CiAgIEFsc28sIHZhcmlvdXMgY2lwaGVycyBzcGVjaWZpZWQgZm9yIHVzZSB3aXRoIFRMUyBhcmUg
a25vd24gdG8gaGF2ZQogICBjcnlwdG9ncmFwaGljIHdlYWtuZXNzZXMgcmVnYXJkbGVzcyBvZiBr
ZXkgbGVuZ3RoIChub25lIG9mIHRoZQogICBjaXBoZXJzIHNwZWNpZmllZCBpbiBbUkZDNDQ5Ml0g
YW5kIFtSRkM1MjQ2XSBjYW4gYmUgcmVjb21tZW5kZWQgZm9yCiAgIHVzZSB3aXRoIEZhbHNlIFN0
YXJ0KS4gIFRoZSBBRVNfMTI4X0dDTV9TSEEyNTYgb3IgQUVTXzI1Nl9HQ01fU0hBMzg0CiAgIGNp
cGhlcnMgc3BlY2lmaWVkIGluIFtSRkM1Mjg4XSBhbmQgW1JGQzUyODldIGNhbiBiZSBjb25zaWRl
cmVkCiAgIHN1ZmZpY2llbnRseSBzdHJvbmcgZm9yIG1vc3QgdXNlcy4gIEltcGxlbWVudGF0aW9u
cyB0aGF0IHN1cHBvcnQKICAgYWRkaXRpb25hbCBjaXBoZXIgc3VpdGVzIGhhdmUgdG8gYmUgY2Fy
ZWZ1bCB0byB3aGl0ZWxpc3Qgb25seQogICBzdWl0YWJsZSBzeW1tZXRyaWMgY2lwaGVyczsgaWYg
aW4gZG91YnQsIEZhbHNlIFN0YXJ0IHNob3VsZCBub3QgYmUKICAgdXNlZCB3aXRoIGEgZ2l2ZW4g
c3ltbWV0cmljIGNpcGhlci4KCiAgIFdoaWxlIGFuIGF0dGFja2VyIGNhbiBjaGFuZ2UgaGFuZHNo
YWtlIG1lc3NhZ2VzIHRvIGZvcmNlIGEgZG93bmdyYWRlCiAgIHRvIGEgbGVzcyBzZWN1cmUgc3lt
bWV0cmljIGNpcGhlciB0aGFuIG90aGVyd2lzZSB3b3VsZCBoYXZlIGJlZW4KICAgY2hvc2VuLCB0
aGlzIHJ1bGUgZW5zdXJlcyB0aGF0IGluIHN1Y2ggYSBkb3duZ3JhZGUgYXR0YWNrIG5vCiAgIGFw
cGxpY2F0aW9uIGRhdGEgd2lsbCBiZSBzZW50IHVuZGVyIGFuIGluc2VjdXJlIHN5bW1ldHJpYyBj
aXBoZXIuCiAgIFdpdGggcmVzcGVjdCB0byBzZXJ2ZXItc2lkZSBGYWxzZSBTdGFydCwgaWYgYSBj
bGllbnQgaGFzIG5lZ290aWF0ZWQgYQogICBUTFMgc2Vzc2lvbiB1c2luZyB3ZWFrIHN5bW1ldHJp
YyBjcnlwdG9ncmFwaHksIHRoaXMgcnVsZSBwcmV2ZW50cwogICBhdHRhY2tlcnMgZnJvbSBzZWVp
bmcgdGhlIHNlcnZlciBlbmNyeXB0IG1vcmUgZGF0YSB1bmRlciB0aGlzIHNlc3Npb24KICAgdGhh
biBub3JtYWxseSAoaWYgYW4gYXR0YWNrZXIgbWFrZXMgdXAgYSAiQ2xpZW50SGVsbG8iIG1lc3Nh
Z2UgYXNraW5nCiAgIHRvIHJlc3VtZSBzdWNoIGEgc2Vzc2lvbiwgbm8gRmFsc2UgU3RhcnQgd2ls
bCBoYXBwZW4pLgoKNi4yLiAgUHJvdG9jb2wgVmVyc2lvbgoKICAgQ2xpZW50cyBNVVNUIE5PVCB1
c2UgdGhlIEZhbHNlIFN0YXJ0IHByb3RvY29sIG1vZGlmaWNhdGlvbiBpbiBhCiAgIGhhbmRzaGFr
ZSB1bmxlc3MgdGhlIHByb3RvY29sIHZlcnNpb24gY2hvc2VuIGJ5CiAgIFNlcnZlckhlbGxvLnNl
cnZlcl92ZXJzaW9uIGhhcyBiZWVuIHdoaXRlbGlzdGVkIGZvciB0aGlzIHVzZS4KCiAgIEdlbmVy
YWxseSwgaW1wbGVtZW50YXRpb25zIHNob3VsZCB3aGl0ZWxpc3Qgb25seSB0aGUgcHJvdG9jb2wK
ICAgdmVyc2lvbihzKSBmb3Igd2hpY2ggdGhleSB3b3VsZCBub3Qgc2VuZCBUTFNfRkFMTEJBQ0tf
U0NTVgogICBbZG93bmdyYWRlLXNjc3ZdLgoKICAgVGhlIGRldGFpbHMgb2Ygbm9taW5hbGx5IGlk
ZW50aWNhbCBjaXBoZXIgc3VpdGVzIGNhbiBkaWZmZXIgYmV0d2VlbgogICBwcm90b2NvbCB2ZXJz
aW9ucywgc28gdGhpcyByZWluZm9yY2VzIFNlY3Rpb24gNi4xLgoKNi4zLiAgS2V5IEV4Y2hhbmdl
IGFuZCBDbGllbnQgQ2VydGlmaWNhdGUgVHlwZQoKICAgQ2xpZW50cyBNVVNUIE5PVCB1c2UgdGhl
IEZhbHNlIFN0YXJ0IHByb3RvY29sIG1vZGlmaWNhdGlvbiBpbiBhCiAgIGhhbmRzaGFrZSB1bmxl
c3MgdGhlIGNpcGhlciBzdWl0ZSB1c2VzIGEga2V5IGV4Y2hhbmdlIG1ldGhvZCB0aGF0IGhhcwog
ICBiZWVuIHdoaXRlbGlzdGVkIGZvciB0aGlzIHVzZS4gIEZ1cnRoZXJtb3JlLCB3aGVuIHVzaW5n
IGNsaWVudAogICBhdXRoZW50aWNhdGlvbiwgY2xpZW50cyBNVVNUIE5PVCB1c2UgdGhlIEZhbHNl
IFN0YXJ0IHByb3RvY29sCiAgIG1vZGlmaWNhdGlvbiB1bmxlc3MgdGhlIGNsaWVudCBjZXJ0aWZp
Y2F0ZSB0eXBlIGhhcyBiZWVuIHdoaXRlbGlzdGVkCiAgIGZvciB0aGlzIHVzZS4KCiAgIEltcGxl
bWVudGF0aW9ucyBtYXkgaGF2ZSB0aGVpciBvd24gd2hpdGVsaXN0cyBvZiBrZXkgZXhjaGFuZ2Ug
bWV0aG9kcwogICBhbmQgY2xpZW50IGNlcnRpZmljYXRlIHR5cGVzIChhbmQgbWF5IGFkZGl0aW9u
YWxseSBhbGxvdyB0aGUKICAgYXBwbGljYXRpb24gbGF5ZXIgdG8gc3BlY2lmeSB3aGl0ZWxpc3Rz
KS4gIEdlbmVyYWxseSwgb3V0IG9mIHRoZQogICBvcHRpb25zIGZyb20gW1JGQzUyNDZdIGFuZCBb
UkZDNDQ5Ml0sIHRoZSBmb2xsb3dpbmcgd2hpdGVsaXN0cyBhcmUKICAgcmVjb21tZW5kZWQ6CgoK
CkxhbmdsZXksIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIsIDIwMTUgICAgICAgICAg
ICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgVExTIEZhbHNl
IFN0YXJ0ICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxNAoKCiAgIG8gIEtleSBleGNoYW5nZSBt
ZXRob2RzOiBESEVfUlNBLCBFQ0RIRV9SU0EsIERIRV9EU1MsIEVDREhFX0VDRFNBCgogICBvICBD
bGllbnQgY2VydGlmaWNhdGUgdHlwZXM6IHJzYV9zaWduLCBkc3Nfc2lnbiwgZWNkc2Ffc2lnbiAo
b3Igbm8KICAgICAgY2xpZW50IGF1dGhlbnRpY2F0aW9uKQoKICAgSG93ZXZlciwgaWYgYW4gaW1w
bGVtZW50YXRpb24gdGhhdCBzdXBwb3J0cyBvbmx5IGtleSBleGNoYW5nZSBtZXRob2RzCiAgIGZy
b20gW1JGQzUyNDZdIGFuZCBbUkZDNDQ5Ml0gZG9lcyBub3Qgc3VwcG9ydCBhbnkgb2YgdGhlIGFi
b3ZlIGtleQogICBleGNoYW5nZSBtZXRob2RzLCBhbGwgb2YgaXRzIHN1cHBvcnRlZCBrZXkgZXhj
aGFuZ2UgbWV0aG9kcyBjYW4gYmUKICAgd2hpdGVsaXN0ZWQgZm9yIEZhbHNlIFN0YXJ0IHVzZS4g
IENhcmUgaXMgcmVxdWlyZWQgd2l0aCBhbnkKICAgYWRkaXRpb25hbCBrZXkgZXhjaGFuZ2UgbWV0
aG9kcyBvciBjbGllbnQgY2VydGlmaWNhdGUgdHlwZXMsIGFzIHRoZXNlCiAgIG1heSBub3QgaGF2
ZSBzaW1pbGFyIHByb3BlcnRpZXMuCgogICBUaGUgcmVjb21tZW5kZWQgd2hpdGVsaXN0cyBhcmUg
c3VjaCB0aGF0IGlmIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcwogICBzdWl0YWJsZSBmb3IgZm9y
d2FyZCBzZWNyZWN5IHdvdWxkIHBvc3NpYmx5IGJlIG5lZ290aWF0ZWQsIG5vIEZhbHNlCiAgIFN0
YXJ0IHdpbGwgdGFrZSBwbGFjZSBpZiB0aGUgY3VycmVudCBoYW5kc2hha2UgZmFpbHMgdG8gcHJv
dmlkZQogICBmb3J3YXJkIHNlY3JlY3kuICAoRm9yd2FyZCBzZWNyZWN5IGNhbiBiZSBhY2hpZXZl
ZCB1c2luZyBlcGhlbWVyYWwKICAgRGlmZmllLUhlbGxtYW4gb3IgZXBoZW1lcmFsIEVsbGlwdGlj
LUN1cnZlIERpZmZpZS1IZWxsbWFuOyB0aGVyZSBpcwogICBubyBmb3J3YXJkIHNlY3JlY3kgd2hl
biBhIHVzaW5nIGtleSBleGNoYW5nZSBtZXRob2Qgb2YgUlNBLCBSU0FfUFNLLAogICBESF9EU1Ms
IERIX1JTQSwgRUNESF9FQ0RTQSwgb3IgRUNESF9SU0EsIG9yIGEgY2xpZW50IGNlcnRpZmljYXRl
IHR5cGUKICAgb2YgcnNhX2ZpeGVkX2RoLCBkc3NfZml4ZWRfZGgsIHJzYV9maXhlZF9lY2RoLCBv
ciBlY2RzYV9maXhlZF9lY2RoLikKICAgQXMgdXN1YWwsIHRoZSBiZW5lZml0cyBvZiBmb3J3YXJk
IHNlY3JlY3kgbWF5IG5lZWQgdG8gYmUgYmFsYW5jZWQKICAgYWdhaW5zdCBlZmZpY2llbmN5LCBh
bmQgYWNjb3JkaW5nbHkgZXZlbiBpbXBsZW1lbnRhdGlvbnMgdGhhdCBzdXBwb3J0CiAgIHRoZSBh
Ym92ZSBrZXkgZXhjaGFuZ2UgbWV0aG9kcyBtaWdodCB3aGl0ZWxpc3QgZnVydGhlciBrZXkgZXhj
aGFuZ2UKICAgbWV0aG9kcyBhbmQgY2xpZW50IGNlcnRpZmljYXRlIHR5cGVzIGZyb20gW1JGQzUy
NDZdIGFuZCBbUkZDNDQ5Ml0uCgo3LiAgQWNrbm93bGVkZ21lbnRzCgogICBUaGUgYXV0aG9ycyB3
aXNoIHRvIHRoYW5rIFdhbi1UZWggQ2hhbmcsIEJlbiBMYXVyaWUsIEVyaWMgUmVzY29ybGEsCiAg
IGFuZCBCcmlhbiBTbWl0aCBmb3IgdGhlaXIgaW5wdXQuCgo4LiAgSUFOQSBDb25zaWRlcmF0aW9u
cwoKICAgTm9uZS4KCjkuICBSZWZlcmVuY2VzCgo5LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoK
ICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8g
SW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAy
MTE5LCBNYXJjaCAxOTk3LgoKICAgW1JGQzQ0OTJdICBCbGFrZS1XaWxzb24sIFMuLCBCb2x5YXJk
LCBOLiwgR3VwdGEsIFYuLCBIYXdrLCBDLiwgYW5kIEIuCiAgICAgICAgICAgICAgTW9lbGxlciwg
IkVsbGlwdGljIEN1cnZlIENyeXB0b2dyYXBoeSAoRUNDKSBDaXBoZXIgU3VpdGVzCiAgICAgICAg
ICAgICAgZm9yIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSIsIFJGQyA0NDkyLCBNYXkg
MjAwNi4KCiAgIFtSRkM1MjQ2XSAgRGllcmtzLCBULiBhbmQgRS4gUmVzY29ybGEsICJUaGUgVHJh
bnNwb3J0IExheWVyIFNlY3VyaXR5CiAgICAgICAgICAgICAgKFRMUykgUHJvdG9jb2wgVmVyc2lv
biAxLjIiLCBSRkMgNTI0NiwgQXVndXN0IDIwMDguCgoKCgpMYW5nbGV5LCBldCBhbC4gICAgICAg
ICAgICBFeHBpcmVzIE1heSAyLCAyMDE1ICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRl
cm5ldC1EcmFmdCAgICAgICAgICAgICAgIFRMUyBGYWxzZSBTdGFydCAgICAgICAgICAgICAgICBP
Y3RvYmVyIDIwMTQKCgogICBbUkZDNTI4OF0gIFNhbG93ZXksIEouLCBDaG91ZGh1cnksIEEuLCBh
bmQgRC4gTWNHcmV3LCAiQUVTIEdhbG9pcwogICAgICAgICAgICAgIENvdW50ZXIgTW9kZSAoR0NN
KSBDaXBoZXIgU3VpdGVzIGZvciBUTFMiLCBSRkMgNTI4OCwKICAgICAgICAgICAgICBBdWd1c3Qg
MjAwOC4KCiAgIFtSRkM1Mjg5XSAgUmVzY29ybGEsIEUuLCAiVExTIEVsbGlwdGljIEN1cnZlIENp
cGhlciBTdWl0ZXMgd2l0aAogICAgICAgICAgICAgIFNIQS0yNTYvMzg0IGFuZCBBRVMgR2Fsb2lz
IENvdW50ZXIgTW9kZSAoR0NNKSIsIFJGQyA1Mjg5LAogICAgICAgICAgICAgIEF1Z3VzdCAyMDA4
LgoKOS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzI2MTZdICBGaWVsZGluZywg
Ui4sIEdldHR5cywgSi4sIE1vZ3VsLCBKLiwgRnJ5c3R5aywgSC4sCiAgICAgICAgICAgICAgTWFz
aW50ZXIsIEwuLCBMZWFjaCwgUC4sIGFuZCBULiBCZXJuZXJzLUxlZSwgIkh5cGVydGV4dAogICAg
ICAgICAgICAgIFRyYW5zZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xIiwgUkZDIDI2MTYsIEp1bmUg
MTk5OS4KCiAgIFtkb3duZ3JhZGUtc2Nzdl0KICAgICAgICAgICAgICBNb2VsbGVyLCBCLiBhbmQg
QS4gTGFuZ2xleSwgIlRMUyBGYWxsYmFjayBTaWduYWxpbmcgQ2lwaGVyCiAgICAgICAgICAgICAg
U3VpdGUgVmFsdWUgKFNDU1YpIGZvciBQcmV2ZW50aW5nIFByb3RvY29sIERvd25ncmFkZQogICAg
ICAgICAgICAgIEF0dGFja3MiLCBXb3JrIGluIFByb2dyZXNzLCBkcmFmdC1pZXRmLXRscy1kb3du
Z3JhZGUtCiAgICAgICAgICAgICAgc2Nzdi0wMSwgTm92ZW1iZXIgMjAxNC4KCkFwcGVuZGl4IEEu
ICBJbXBsZW1lbnRhdGlvbiBOb3RlcwoKICAgVExTIEZhbHNlIFN0YXJ0IGlzIGEgbW9kaWZpY2F0
aW9uIHRvIHRoZSBUTFMgcHJvdG9jb2wsIGFuZCBzb21lCiAgIGltcGxlbWVudGF0aW9ucyB0aGF0
IGNvbmZvcm0gdG8gW1JGQzUyNDZdIG1heSBoYXZlIHByb2JsZW1zCiAgIGludGVyYWN0aW5nIHdp
dGggaW1wbGVtZW50YXRpb25zIHRoYXQgdXNlIHRoZSBGYWxzZSBTdGFydAogICBtb2RpZmljYXRp
b24uICBJZiB0aGUgcGVlciB1c2VzIGEgRmFsc2UgU3RhcnQsIGFwcGxpY2F0aW9uIGRhdGEKICAg
cmVjb3JkcyBtYXkgYmUgcmVjZWl2ZWQgZGlyZWN0bHkgZm9sbG93aW5nIHRoZSBwZWVyJ3MgIkZp
bmlzaGVkIgogICBtZXNzYWdlLCBiZWZvcmUgdGhlIFRMUyBpbXBsZW1lbnRhdGlvbiBoYXMgc2Vu
dCBpdHMgb3duICJGaW5pc2hlZCIKICAgbWVzc2FnZS4gIEZhbHNlIFN0YXJ0IGNvbXBhdGliaWxp
dHkgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMgZW5zdXJlcwogICB0aGF0IHRoZXNlIHJlY29yZHMg
d2l0aCBhcHBsaWNhdGlvbiBkYXRhIHdpbGwgc2ltcGx5IHJlbWFpbiBidWZmZXJlZAogICBmb3Ig
bGF0ZXIgcHJvY2Vzc2luZy4KCiAgIEEgRmFsc2UgU3RhcnQgY29tcGF0aWJsZSBUTFMgaW1wbGVt
ZW50YXRpb24gZG9lcyBub3QgaGF2ZSB0byBiZSBhd2FyZQogICBvZiB0aGUgRmFsc2UgU3RhcnQg
Y29uY2VwdCwgYW5kIGlzIGNlcnRhaW5seSBub3QgZXhwZWN0ZWQgdG8gZGV0ZWN0CiAgIHdoZXRo
ZXIgYSBGYWxzZSBTdGFydCBoYW5kc2hha2UgaXMgY3VycmVudGx5IHRha2luZyBwbGFjZTogdGhh
bmtzIHRvCiAgIHRyYW5zcG9ydCBsYXllciBidWZmZXJpbmcsIHR5cGljYWwgaW1wbGVtZW50YXRp
b25zIHdpbGwgYmUgRmFsc2UKICAgU3RhcnQgY29tcGF0aWJsZSB3aXRob3V0IGhhdmluZyBiZWVu
IGRlc2lnbmVkIGZvciBpdC4KCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAgQWRhbSBMYW5nbGV5CiAg
IEdvb2dsZSBJbmMuCiAgIDM0NSBTcGVhciBTdAogICBTYW4gRnJhbmNpc2NvLCBDQSAgOTQxMDUK
ICAgVVNBCgogICBFbWFpbDogYWdsQGdvb2dsZS5jb20KCgoKCkxhbmdsZXksIGV0IGFsLiAgICAg
ICAgICAgIEV4cGlyZXMgTWF5IDIsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCklu
dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgVExTIEZhbHNlIFN0YXJ0ICAgICAgICAgICAgICAg
IE9jdG9iZXIgMjAxNAoKCiAgIE5hZ2VuZHJhIE1vZGFkdWd1CiAgIEluZGVwZW5kZW50CgogICBF
bWFpbDogbmFnZW5kcmFAY3Muc3RhbmZvcmQuZWR1CgoKICAgQm9kbyBNb2VsbGVyCiAgIEdvb2ds
ZSBTd2l0emVybGFuZCBHbWJICiAgIEJyYW5kc2NoZW5rZXN0cmFzc2UgMTEwCiAgIFp1cmljaCAg
ODAwMgogICBTd2l0emVybGFuZAoKICAgRW1haWw6IGJtb2VsbGVyQGFjbS5vcmcKCgoKCgoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpMYW5nbGV5LCBldCBhbC4gICAgICAgICAgICBF
eHBpcmVzIE1heSAyLCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAxMV0K
--089e0160c47824197b05068f6680--


From nobody Wed Oct 29 10:50:36 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6CA1A875A for ; Wed, 29 Oct 2014 10:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.559
X-Spam-Level: 
X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATWdu4hp9oPo for ; Wed, 29 Oct 2014 10:50:29 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3D91A8756 for ; Wed, 29 Oct 2014 10:50:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.07,278,1413237600";  d="p7s'?scan'208,217";a="103612900"
Received: from wifi-auth-189207.inria.fr ([128.93.189.207]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Oct 2014 18:50:25 +0100
Content-Type: multipart/signed; boundary="Apple-Mail=_628F8125-54F0-4A12-ABA2-434BDA1CF3CE"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Benjamin Beurdouche 
In-Reply-To: 
Date: Wed, 29 Oct 2014 18:50:25 +0100
Message-Id: <24E42610-6B9B-43A5-9167-21C68DBC415A@inria.fr>
References: <20141027221408.23949.47145.idtracker@ietfa.amsl.com> 
To: Thulasi 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zyh2UI-sP2GOYNHA2OHO4mTyFyY
Cc: ML IETF TLS 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-03.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 17:50:33 -0000

--Apple-Mail=_628F8125-54F0-4A12-ABA2-434BDA1CF3CE
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_DC48CDC9-53DE-48BA-B208-D4C46609DB28"


--Apple-Mail=_DC48CDC9-53DE-48BA-B208-D4C46609DB28
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

It is a typo=E2=80=A6 Anyway, it still to be decided how to handle =
resumption in 1.3.
We still don=E2=80=99t know how resumption will be modified because of =
the PFS problem. Maybe we will simply discard it in favour of another =
mechanism if the WG considers it is good enough, for instance a =
potential 0RTT, but from last week interim meeting I think we are far =
from consensus...
I don=E2=80=99t expect this part of the draft to end up on Eric=E2=80=99s =
todo list until the WG agree upon a concrete solution.

Cheers,
B.

> On 29 Oct 2014, at 12:39, Thulasi  =
wrote:
>=20
> In Figure 3 (Message flow for an abbreviated handshake),
> what does ClientKeyExhange message along with ClientHello signify?=20
>=20
> Thanks,
> Thulasi.
>=20
> On 28 October 2014 03:40, Internet-Drafts Administrator [via IETF] =
<[hidden email] =
> wrote:
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.=20
>  This draft is a work item of the Transport Layer Security Working =
Group of the IETF.=20
>=20
>         Title           : The Transport Layer Security (TLS) Protocol =
Version 1.3=20
>         Authors         : Tim Dierks=20
>                           Eric Rescorla=20
>         Filename        : draft-ietf-tls-tls13-03.txt=20
>         Pages           : 93=20
>         Date            : 2014-10-27=20
>=20
> Abstract:=20
>    This document specifies Version 1.3 of the Transport Layer Security=20=

>    (TLS) protocol.  The TLS protocol provides communications security=20=

>    over the Internet.  The protocol allows client/server applications =
to=20
>    communicate in a way that is designed to prevent eavesdropping,=20
>    tampering, or message forgery.=20
>=20
>=20
> The IETF datatracker status page for this draft is:=20
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ =

>=20
> There's also a htmlized version available at:=20
> http://tools.ietf.org/html/draft-ietf-tls-tls13-03 =

>=20
> A diff from the previous version is available at:=20
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-03 =

>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission=20
> until the htmlized version and diff are available at tools.ietf.org =
.=20
>=20
> Internet-Drafts are also available by anonymous FTP at:=20
> ftp://ftp.ietf.org/internet-drafts/ =
=20
>=20
> _______________________________________________=20
> TLS mailing list=20
> [hidden email] =20
> https://www.ietf.org/mailman/listinfo/tls =

>=20
>=20
> If you reply to this email, your message will be added to the =
discussion below:
> =
http://ietf.10.n7.nabble.com/I-D-Action-draft-ietf-tls-tls13-03-txt-tp4364=
05.html =

> To start a new topic under IETF - TLS, email [hidden email] =
=20
> To unsubscribe from IETF - TLS, click here =
.
> NAML =

>=20
> View this message in context: Re: I-D Action: =
draft-ietf-tls-tls13-03.txt =

> Sent from the IETF - TLS mailing list archive =
 at Nabble.com.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--Apple-Mail=_DC48CDC9-53DE-48BA-B208-D4C46609DB28
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Hi,

It is a typo=E2=80=A6 Anyway, it still to be decided =
how to handle resumption in 1.3.
We still don=E2=80=99t =
know how resumption will be modified because of the PFS problem. Maybe =
we will simply discard it in favour of another mechanism if the WG =
considers it is good enough, for instance a potential 0RTT, but from =
last week interim meeting I think we are far from consensus...
I don=E2=80=99t expect this part of the draft to end up on =
Eric=E2=80=99s todo list until the WG agree upon a concrete =
solution.

Cheers,
B.

On =
29 Oct 2014, at 12:39, Thulasi <thulasi.goriparthi@gmail.com> wrote:

In Figure 3 (Message flow for an abbreviated =
handshake),
what does ClientKeyExhange message along with =
ClientHello signify? 

Thanks,
Thulasi.

On 28 October 2014 03:40, Internet-Drafts =
Administrator [via IETF] <[hidden =
email]> wrote:


	
A New Internet-Draft is available from the =
on-line Internet-Drafts directories.

 This draft is a work item of the Transport Layer =
Security Working Group of the IETF.


        Title   =
        : The Transport Layer Security (TLS) =
Protocol Version 1.3

        Authors       =
  : Tim Dierks

                =
          Eric Rescorla

        Filename       =
 : draft-ietf-tls-tls13-03.txt

        Pages       =
    : 93

        Date       =
     : 2014-10-27


Abstract:

   This document specifies Version 1.3 of the =
Transport Layer Security

   (TLS) protocol.  The TLS protocol =
provides communications security

   over the Internet.  The protocol allows =
client/server applications to

   communicate in a way that is designed to =
prevent eavesdropping,

   tampering, or message forgery.



The IETF datatracker status =
page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

There's also a htmlized version available at:

http://tools.ietf.org/html/draft-ietf-tls-tls13-03

A diff from the previous version is available =
at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-03<=
br class=3D"">

Please note that it may take =
a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.


Internet-Drafts are also available by =
anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/


_______________________________________________

TLS mailing list

[hidden =
email]

https://www.ietf.org/mailman/listinfo/tls


=09
=09
=09
	

	

	

	

		
If you reply =
to this email, your message will be added to the discussion below:

		http://ietf.10.n7.nabble.com/I-D-Action-draft-ietf-tls-tls13-03=
-txt-tp436405.html
	

	

		To start a new topic under IETF - TLS, email [hidden =
email] 

		To unsubscribe from IETF - TLS, click =
here.

		NAML
	




=09
=09
=09


View this message in context: Re: I-D Action: =
draft-ietf-tls-tls13-03.txt

Sent from the IETF - TLS mailing list archive at Nabble.com.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

=

--Apple-Mail=_DC48CDC9-53DE-48BA-B208-D4C46609DB28--

--Apple-Mail=_628F8125-54F0-4A12-ABA2-434BDA1CF3CE
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN9zCCBIow
ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0
d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa
Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh
bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0
dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0
aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF
pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk
xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q
L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs
vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe
oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3
+sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC
AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh
LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u
bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis
pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0
g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK
322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk
LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/
0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIEnjCCA4agAwIBAgIRANlQHbDQ8Bume0KUCx8iWUEwDQYJ
KoZIhvcNAQEFBQAwOzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRFUkVOQTEbMBkGA1UEAxMSVEVS
RU5BIFBlcnNvbmFsIENBMB4XDTEzMDUwNTAwMDAwMFoXDTE2MDUwNDIzNTk1OVowXTELMAkGA1UE
BhMCRlIxDjAMBgNVBAoTBUlOUklBMRwwGgYDVQQDExNCZW5qYW1pbiBCRVVSRE9VQ0hFMSAwHgYJ
KoZIhvcNAQkCFhFiYmV1cmRvdUBpbnJpYS5mcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAMKRXzG4fGhz27DJuClq0F14lJx6qmYZyBMUtlG6l6MzvPrRqyDTpn7c0RHoBa3s5ZEJ2EM0
BTTt8h8P8hIFnqXDvGJqa960E1qtf6V4TAi0I0+ZJAXLQvFhRWeXm4zevKiO1mazCqt/qc707g0G
jneWjrzEvN7RqcB60o6g6muFmEpMqUymNlC+L2fl3uWcmRc4LF8VGm+jsdVc+5pdU7HVVyfmjJHg
IXFx6r6KPY1EPrP+StLViPYr5VSudeU1sogXxrPeXFMwXCrBd2OKIg5QmCkvApas/LthnlRuBEfD
7zVg3G1xkNOcwZocfkaGCyywenTrwQqmQ7yoxrO4kaECAwEAAaOCAXkwggF1MB8GA1UdIwQYMBaA
FGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1UdDgQWBBTdo5AEhwP7YOpw+F9pzqpk3zk+UTAOBgNV
HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw
GAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRj
cy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFsQ0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEF
BQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5hLm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggr
BgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRlcmVuYS5vcmcwJwYDVR0RBCAwHoEcYmVuamFtaW4u
YmV1cmRvdWNoZUBpbnJpYS5mcjANBgkqhkiG9w0BAQUFAAOCAQEAr4FExpaL6tnXFF7L0JKNNrQ2
OHHJ+iqMZfeN6UTSKxNcWYDY55OM+McD9o8qU2D6wBofC0Dve6eLOiShjEdlcWFt5KdAIfiA0NLz
j8sNwt5wGkxmPW1j421nH5YjLUItgRqr0NXu/wJFabIe4WevptHSgZYJYdNJPE1sGsF20aWonPPJ
K9JqbkgS0CKuXwwwFUd/QEtaNhPsr9XqG1k3tDuaThdvptZ3vuVxsLk+jLUfHM+Fv3b6me3M2pvG
FOvpiB4JgpUqKeCDUNxcDCihRWBBPFgWW8fmUU93KPs6LB6nmlMY+pDqyMmHqfRR/yiXALyUzhYF
AAm86nnH29KmAjCCBMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAw
ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAc
BgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1
c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMDkwNTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0G
A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfc
dYBBS2Qa9ttPb4/QJUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264K
ZSUih9pvhItG6ECGKD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTE
TdDLJ/qEZObRl51WJFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+
zj1O9CtQEUvRWNSbA/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIB
STAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6
v+4O5YK3ZqYwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzAN
BgsrBgEEAbIxAQICHTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20v
VVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcB
AQRjMGEwOAYIKwYBBQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRf
Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB
BQUAA4IBAQAGK6lTLxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkD
Mvp1gziKu2uapQwTstQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t
2SNy5JzOOlxsH0+pAMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9
d19AIeZ/HaWWWr3QyxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3n
XhXcJ4bkOjtSWherqQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICnDCCApgCAQEwUDA7MQswCQYD
VQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEQDZ
UB2w0PAbpntClAsfIllBMAkGBSsOAwIaBQCgggEhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTE0MTAyOTE3NTAyNlowIwYJKoZIhvcNAQkEMRYEFKcB+PzEqYZevItq
BAZVlH1af8iyMF8GCSsGAQQBgjcQBDFSMFAwOzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRFUkVO
QTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBAhEA2VAdsNDwG6Z7QpQLHyJZQTBhBgsqhkiG
9w0BCRACCzFSoFAwOzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRFUkVOQTEbMBkGA1UEAxMSVEVS
RU5BIFBlcnNvbmFsIENBAhEA2VAdsNDwG6Z7QpQLHyJZQTANBgkqhkiG9w0BAQEFAASCAQA3hG+b
3jhTDHJwT6P4Xty2RuYpM1qOcpQ2THQ1/DD7OKKENHgVxRfgEFleO5SXq4d9ijgzXadbyqqCSDRf
rFLL7RToSHQ6D5hcgRLvybfAs1BrF5tf/lbZPPBOC3FxgwGwd4byDq+L5GBGdHIyhBDTjcuqoKk4
ic4fqPSxOsqVsFhkN7tm6wbY8zyg4rbxXJ8Pj2mRw7af6oUglFO2ybOSUGAKOfLxlzN8lrpnYPxo
oBMGq53wBeikdwAgOMxq/4bud8Mgjs/dUZLlOg4pYy7wEbCtinFrVSCEuPx3no1rv52bWaPGjHUo
gHgtn69bsrEXMJQ5daQTieakzmk/8f0wAAAAAAAA
--Apple-Mail=_628F8125-54F0-4A12-ABA2-434BDA1CF3CE--


From nobody Wed Oct 29 13:27:54 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6831A8914 for ; Wed, 29 Oct 2014 13:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU3mtRLS82f3 for ; Wed, 29 Oct 2014 13:27:48 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF2F1A88F8 for ; Wed, 29 Oct 2014 13:27:47 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id B28A66B49E; Wed, 29 Oct 2014 21:27:45 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id A764643F4A; Wed, 29 Oct 2014 21:27:45 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9CB281AF69; Wed, 29 Oct 2014 21:27:45 +0100 (CET)
In-Reply-To: 
To: Bodo Moeller 
Date: Wed, 29 Oct 2014 21:27:45 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141029202745.9CB281AF69@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qyzueOzMznmwvqBqSmbXKBtWroo
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 20:27:52 -0000

Bodo Moeller wrote:
> 
> Continuing the handshake would not require any app-level changes to Servers
> > that have not been writing fatal SSL alerts to the network before
> > connection closure in the past, such as Microsoft IIS, so clients
> > with fallback heuristics will be in a *MUCH* better position to
> > recognize and distinguish accidental network glitches or connection
> > management bugs from attacks.  I expect the false positives to
> > outnumber attacks by at least three orders of magnitudes.
> 
> If there's an *actual* attack and the client doesn't continue with the
> connection, the attacker can suppress alert details anyway. The alert (if
> it gets through) is useful for heuristics; the only definitive protection
> is from making sure that the client and server won't exchange application
> data.

I believe we're still talking past each other.

It will be impossible to protect the handshakes between two TLS peers
where one of them does not know about the FALLBACK_SCSV.

We're discussing purely the situation where _both_ sides are patched.


With the current proposal, the server is supposed to abort the handshake,
but with pretty much no useful information to perform any kind of sensible
risk management, no means to cause the client to retry with "more features",
and not the slightest clue what "more features" really means.


If instead, the server includes a ServerHelloExtension when recognizing
the Fallback SCSV, then the client will have *MUCH* better information
available to make sensible risk management:
   - only the client knows *which* features it actually omitted
   - only the client knows how often it has tried to perform the handshake
     (how long he has been doing the "downgrade dance") on the current
     request.
   - only the client can decide to perform another request with 
     more/better options than what the server picked and returned in
     ServerHello
   - only the client can tell the user/admin about what happend
     (how often and how far it attempted to downgrade) and obtain
     a confirmation whether to continue/retry or abort.

It's up to you / the WG to decide what the contents / semantics of
such a ServerHelloExtension should be, i.e. whether the presence
of the extension is a simple Boolean with a meaning closer to
the currently suggested fatal alert (i.e. an encouragement for the
client to abort and reconnect), or whether there should be a more
fine grained response, such as a structure that conveys the highest
protocol version of the server, whether the TLS server understands
and would appreciate TLS extensions or even a list of TLS extensions
that the server would _really_ like to see (such as ECC, SNI, ...)
or whether the server would really appreciate being offered
a larger variety of TLS cipher suites.


I've been doing customer support for almost 20 years, I'm not just
doing software development and maintenance, and the type of support
that I do includes analyzing and explaining to customers interop failures
when trying to access TLS-protected resources and suggesting them how
to change their configuration in order to obtain interop.

Interop failures that end with a fatal SSL alert or silent connection
closure are a royal pain to analyze, which is why I will never consider
a specification as the current one (neither on the client, nor on
the server side).   Both, as IETF TLS WG and as software engineer(s),
we can do *MUCH* better easily.


-Martin


From nobody Wed Oct 29 13:43:16 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE74B1A8ABC for ; Wed, 29 Oct 2014 13:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.251
X-Spam-Level: 
X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYPZ0BTPM6VV for ; Wed, 29 Oct 2014 13:43:12 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8F11A88D7 for ; Wed, 29 Oct 2014 13:43:12 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 551F43A177; Wed, 29 Oct 2014 21:43:11 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 4529C43E30; Wed, 29 Oct 2014 21:43:11 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3E9611AF68; Wed, 29 Oct 2014 21:43:11 +0100 (CET)
In-Reply-To: <5450CFC1.2020308@polarssl.org>
To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?= 
Date: Wed, 29 Oct 2014 21:43:11 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20141029204311.3E9611AF68@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yU0UOtXVCt1RVgZYZ9DJ_g24yxI
Cc: Florian Weimer , tls@ietf.org
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 20:43:16 -0000

Manuel P=E9gouri=E9-Gonnard wrote:
> On 29/10/2014 12:18, Florian Weimer wrote:
>>=20
>> I think the SSLv2 compatible client hello is unrelated to the protocol
>> version advertised by the client, but I might be mistaken about that.

Correct.  You can negotiate TLSv1.2 on a connection that is started
with a SSL VERSION 2.0 CLIENT-HELLO.


>
> Unless I'm mistaken, there is no point for a client to send a SSLv2
> compatible ClientHello unless the client is prepared to actually
> negotiate SSLv2. If think if fair to say that client MUST NOT do that.

You might be surprised just how much crap (as servers) got shipped into
the installed base, and what turns out to be the most suitable workaround
to interop with those.

The problem with SSLv3 & ClientHello protocol version negotiation is
that a number of servers totally goofed the implementation, and a number
of clients (pretty much all browsers) followed suit.

The issue with TLS protocol version negotiation is that the SSLv3&TLS record
layer uses a "protocol_version" tag in the record layer PDU that indicates
_the_record_layer_PDU_encoding_, and when an initial ClientHello
is received on a new connection, there is also a ClientHello.client_version
field included.  A number of broken servers screwed up the protocol
version negotiation (which is performed EXCLUSIVELY through
ClientHello.client_version) by choking on the record layer PDU encoding
protocol_version when it differs from ClientHello.client_version.

Now the advantage of the SSL VERSION 2.0 CLIENT-HELLO is that it comes
with only a single protocol version -- and it seems that less server
implementors got that wrong.



>=20
> OTOH, accepting an SSLv2 ClientHello on the server makes sense even if the
> server will never negotiate SSLv2. So I guess the MAY here is ok.

We already settled the SSLv2 ClientHello issues.

http://tools.ietf.org/html/rfc6176#section-3


-Martin


From nobody Wed Oct 29 14:02:43 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85671A1A2D for ; Wed, 29 Oct 2014 14:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-WC1IEFASkY for ; Wed, 29 Oct 2014 14:02:40 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2731A902B for ; Wed, 29 Oct 2014 14:02:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=Ouz93Pl93VA3Kix+ZiAEfxkg9YShzdxqAcz2HIDhrGc=;  b=E7uTUNzv/X8AloswGbialgIP8N3EZ9JnTMnyq/me53Ju/GERNlGhHmWCUhERZdGb+6lUaXTkAvJFcYHo6s5W19qlDk8ywEvXgyPpuiblLmNaR0bEr7gChMLp2yjynlbmtEHe9p9FUUG86a20SIyUPw7xUMCxp3u/GRJbHCfmM6E=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XjaNq-0001uP-5K; Wed, 29 Oct 2014 22:02:31 +0100
Message-ID: <545155E2.2070203@polarssl.org>
Date: Wed, 29 Oct 2014 22:02:26 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: mrex@sap.com
References: <20141029204311.3E9611AF68@ld9781.wdf.sap.corp>
In-Reply-To: <20141029204311.3E9611AF68@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9vDpUm-qkRahidf9X6ZWKo2uK50
Cc: Florian Weimer , tls@ietf.org
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 21:02:42 -0000

On 29/10/2014 21:43, Martin Rex wrote:
> Manuel Pégourié-Gonnard wrote:
>> Unless I'm mistaken, there is no point for a client to send a SSLv2
>> compatible ClientHello unless the client is prepared to actually
>> negotiate SSLv2. If think if fair to say that client MUST NOT do that.
> 
> [...]            A number of broken servers screwed up the protocol
> version negotiation (which is performed EXCLUSIVELY through
> ClientHello.client_version) by choking on the record layer PDU encoding
> protocol_version when it differs from ClientHello.client_version.
> 
> Now the advantage of the SSL VERSION 2.0 CLIENT-HELLO is that it comes
> with only a single protocol version -- and it seems that less server
> implementors got that wrong.
> 
Ok, I didn't know, thanks for the info.

>> OTOH, accepting an SSLv2 ClientHello on the server makes sense even if the
>> server will never negotiate SSLv2. So I guess the MAY here is ok.
> 
> We already settled the SSLv2 ClientHello issues.
> 
> http://tools.ietf.org/html/rfc6176#section-3
> 
Yes, I'd forgotten that until Bodo mentioned it.

Manuel.


From nobody Wed Oct 29 17:13:53 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0A21ACE1E for ; Wed, 29 Oct 2014 17:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-aC8Df3Rxch for ; Wed, 29 Oct 2014 17:13:49 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568CD1ACE16 for ; Wed, 29 Oct 2014 17:13:49 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 1C32154481; Thu, 30 Oct 2014 01:13:46 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id BAC9A42FB9; Thu, 30 Oct 2014 01:13:46 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id AF51B1AF69; Thu, 30 Oct 2014 01:13:46 +0100 (CET)
In-Reply-To: <1414598692.723.59.camel@dhcp-2-127.brq.redhat.com>
To: Nikos Mavrogiannopoulos 
Date: Thu, 30 Oct 2014 01:13:46 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20141030001346.AF51B1AF69@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xXb-pDmVajr6W60qjYONV2PJ9b8
Cc: "" 
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 00:13:51 -0000

Nikos Mavrogiannopoulos wrote:
> On Wed, 2014-10-29 at 15:30 +0000, Peter Gutmann wrote:
>> Manuel P=E9gouri=E9-Gonnard  writes:
>>=20
>>>The *only* difference is (something that doesn't involve the definition =
of
>>>length), so the definition of the length is unchanged, therefore it's th=
e one
>>>from RFC 5246.
>>=20
>> No it isn't.  RFC 7366 moves the MAC outside the GenericXXXCipher fragme=
nt,
>> so it's no longer included.
>=20
> I don't think it matter that the MAC is outside the GenericXXXCipher
> fragment.

On the contrary, this matters a whole lot.



> TLSCiphertext is defined in RFC7366 as follows:
>=20
>    struct {
>           ContentType type;
>           ProtocolVersion version;
>           uint16 length;
>           GenericBlockCipher fragment;
>           opaque MAC;
>           } TLSCiphertext;
>=20
> (for block ciphers at least). That TLSCiphertext.length send on the wire
> contains both fragment and MAC length, doesn't it?


This is the rfc5246 definition of TLSCiphertext and the explanation
of the "length" element within that structure:

http://tools.ietf.org/html/rfc5246#section-6.2.3

      struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length;
          select (SecurityParameters.cipher_type) {
              case stream: GenericStreamCipher;
              case block:  GenericBlockCipher;
              case aead:   GenericAEADCipher;
          } fragment;
      } TLSCiphertext;

   type
      The type field is identical to TLSCompressed.type.

   version
      The version field is identical to TLSCompressed.version.

   length
      The length (in bytes) of the following TLSCiphertext.fragment.
      The length MUST NOT exceed 2^14 + 2048.

   fragment
      The encrypted form of TLSCompressed.fragment, with the MAC.


In rfc5246, the "length" element of the TLSCiphertext structure
contains the length of the "fragment" element directly following it,
and rfc7366.   But rfc7366 moves the MAC outside of the fragment,
so its length will no longer be included in the TLSCiphertext.length
count.


Curiously, rfc7366 doesn't indicate the real length of the MAC element
in the same fashion that rfc5246 does:

  rfc5246:   opaque MAC[SecurityParameters.mac_length];

  rfc7366:   opaque MAC;

...but then, rfc2246 and rfc4346 used slightly different names/terminology
for the SecurityParameters, and would use:
             opaque MAC[SecurityParameters.hash_size];



-Martin


From nobody Thu Oct 30 01:06:14 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A384B1AD04E for ; Thu, 30 Oct 2014 01:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qt4SPs386_zf for ; Thu, 30 Oct 2014 01:06:12 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036F91AD04C for ; Thu, 30 Oct 2014 01:06:11 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9U865FS003465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 30 Oct 2014 04:06:05 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9U8615l002506 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 04:06:03 -0400
Message-ID: <1414656361.4213.9.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: mrex@sap.com
Date: Thu, 30 Oct 2014 09:06:01 +0100
In-Reply-To: <20141030001346.AF51B1AF69@ld9781.wdf.sap.corp>
References: <20141030001346.AF51B1AF69@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OvHlMroxyE1OQPiD3eFJBz6sBiw
Cc: "" 
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 08:06:13 -0000

On Thu, 2014-10-30 at 01:13 +0100, Martin Rex wrote:

> > TLSCiphertext is defined in RFC7366 as follows:
> > 
> >    struct {
> >           ContentType type;
> >           ProtocolVersion version;
> >           uint16 length;
> >           GenericBlockCipher fragment;
> >           opaque MAC;
> >           } TLSCiphertext;
> > 
> > (for block ciphers at least). That TLSCiphertext.length send on the wire
> > contains both fragment and MAC length, doesn't it?
> 
> 
> This is the rfc5246 definition of TLSCiphertext and the explanation
> of the "length" element within that structure:
> 
> http://tools.ietf.org/html/rfc5246#section-6.2.3
> 
>       struct {
>           ContentType type;
>           ProtocolVersion version;
>           uint16 length;
>           select (SecurityParameters.cipher_type) {
>               case stream: GenericStreamCipher;
>               case block:  GenericBlockCipher;
>               case aead:   GenericAEADCipher;
>           } fragment;
>       } TLSCiphertext;
> 
>    type
>       The type field is identical to TLSCompressed.type.
> 
>    version
>       The version field is identical to TLSCompressed.version.
> 
>    length
>       The length (in bytes) of the following TLSCiphertext.fragment.
>       The length MUST NOT exceed 2^14 + 2048.
> 
>    fragment
>       The encrypted form of TLSCompressed.fragment, with the MAC.
> 
> 
> In rfc5246, the "length" element of the TLSCiphertext structure
> contains the length of the "fragment" element directly following it,
> and rfc7366.   But rfc7366 moves the MAC outside of the fragment,
> so its length will no longer be included in the TLSCiphertext.length
> count.

Correct. Thus the length sent on the wire must also not include the MAC
size. So is my understanding correct that no deployed implementation is
compliant to rfc7366 so far?

regards,
Nikos



From nobody Thu Oct 30 02:12:35 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D8A1AD046 for ; Thu, 30 Oct 2014 02:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6eCMMVyGCOw for ; Thu, 30 Oct 2014 02:12:32 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C711A6FC6 for ; Thu, 30 Oct 2014 02:12:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=84Q1CD6zT4EVu0IyXjiAYSc7JgOE/aYS1q+i/Q5gFDA=;  b=iCvY7IzWjSBF7bd2LhsDBPWn0c1CKAu5cXYjfH8+9vOiPFvSzh1Ok6j2LpxySsJ9y4DqvpkPKwsG2SGq5tqKVtHiOsN9a0sK0EUj6HoCK//ZxdRux+n5rd8QB7i9D+VdLG4ZKJyrmM7kb8sBR3vVVVgeQLJTc4+Vu4pyymR8sy8=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XjlmK-0002cG-NI; Thu, 30 Oct 2014 10:12:25 +0100
Message-ID: <545200FD.1030302@polarssl.org>
Date: Thu, 30 Oct 2014 10:12:29 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos , mrex@sap.com
References: <20141030001346.AF51B1AF69@ld9781.wdf.sap.corp> <1414656361.4213.9.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1414656361.4213.9.camel@dhcp-2-127.brq.redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hQqRQjA32zCN7qErCY3EXrJ4tdE
Cc: "" 
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 09:12:34 -0000

On 30/10/2014 09:06, Nikos Mavrogiannopoulos wrote:
> Correct. Thus the length sent on the wire must also not include the MAC
> size. So is my understanding correct that no deployed implementation is
> compliant to rfc7366 so far?

I feel it's the third time this point about what goes on the wire is made (2
times by Nikos and 1 by me) and it didn't get any answer so far, while it is IMO
crucial. I'd really like a direct answer to this.

Let me recap. With RFC 5246 the following are true:
1. TLSCiphertext.length is the length of TLSCiphertext.fragment
2. TLSCiphertext.length is the length that goes on the wire.
3. The length that goes on the wire is the length of the rest of the recordą.

So far I've seen many arguments that it's obvious that (1) must continue to hold
in the context of RFC 7366, but I'd like to see the other points discussed.
Specifically, I hope we all agree that it's impossible for all of the 3 points
to simultaneously remain true in the context of RFC 7366.

The implementation on the eid server made the choice that (1) and (3) remain
true, but (2) becomes false. This contradicts the text of RFC 7366 which says:
"The overall TLS packet [2] is then: [definition of] TLSCiphertext", confirming
that TLSCiphertext is still what goes on the wire.

The choice I spontaneously made when first implementing it (without as much
analysis as I'm doing now) is that (2) and (3) are pretty fundamental
assumptions so it was "obvious" (to me!) that (1) was to be violated by changing
the definition of TLSCiphertext.length to be "length of TLSCiphertext.fragment +
MAC".

Now, I don't want to discuss which of these options is the best˛ or the most
natural interpretation of RFC 7366. My point is, RFC 7366 is ambiguous since it
forces the reader to guess/choose which of the above three points changes
instead of stating it explicitly. This should be fixed.

Manuel.

-----
ą While it's not explicitly stated in RFC 5246, it's true of the three record
types it defines, and is a pretty important assumption in many implementations.
Violating this assumption would make any RFC much harder to implement/deploy.

˛ I think it's clear that unless there already are mutually incompatible
implementations deployed, we really want the new implementations to be
compatible with the deployed ones.


From nobody Thu Oct 30 02:19:44 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC471AD056 for ; Thu, 30 Oct 2014 02:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYllff98DG6V for ; Thu, 30 Oct 2014 02:19:39 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206501A6FC6 for ; Thu, 30 Oct 2014 02:19:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=IxlxlKbFrlg59nwHJsswCyuYMMxA8ib/Sr2X8sHm6mo=;  b=Hs+WHtZo5TB3jaoOb2EtLxI/u1YAanW7BUIAVsPhT3bQw5JxGzlXHpw0hVmMnXOqrCUNXXzET02VxEZwmit5CbT/w1JuBbQXu/jTO+p9TWH+QQiAJX3E9xylDIRePReicqNvq0cIGWuVV2Yweg8LvRvD1XUCHaSTISx7zncbu4w=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XjltD-0002ct-0M; Thu, 30 Oct 2014 10:19:31 +0100
Message-ID: <545202A7.7050603@polarssl.org>
Date: Thu, 30 Oct 2014 10:19:35 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Peter Gutmann , "" 
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB460@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB460@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uCqXIwnSC1mXlbkMFxFKpOtqbRk
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 09:19:39 -0000

On 29/10/2014 16:30, Peter Gutmann wrote:
> [...] In fact it doesn't even make any sense to include
> the MAC length, if you tell your code to MAC the length of the ciphertext plus
> the length of the MAC you'll end up MACing 20 or 32 bytes of whatever random
> data happens to be present at the end of the ciphertext.

Sure, I'd never think of doing that. But I can certainly tell my code to compute

  MAC_k( seq_num + type + version + length + encrypted_stuff )

with length != length_of(encrypted_stuff). After all, for the MAC function, what
we call "length" is just two meaningless bytes.

Manuel.


From nobody Thu Oct 30 02:40:33 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4AF1AD074 for ; Thu, 30 Oct 2014 02:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqkwWvgXmmi7 for ; Thu, 30 Oct 2014 02:40:27 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CC031AD071 for ; Thu, 30 Oct 2014 02:40:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414662027; x=1446198027; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=XsySAJgKCg5tAg0mwKMn05FYGrGjaczKYSrrqn+d6hQ=; b=hZUGsMC/rCkIGkfoGRUu1p97aKGGSdO/p8HSXTmvRrslDsrPPLnQYM5y TYcgZ5KwWU3vHb+c2poBnyIPTGp6mut9bIQwhzoqVb4T2bhWAajE1T9yx ceEHH9Qy4Mstagd7kUN0o2kzGUo2Mm6s6WgbHJNw2DR6m2DlpElz9F6ew A=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286657948"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Oct 2014 22:40:25 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 22:40:25 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/0JYdwMQsIUTUTR26tLWCCKHmDfA==
Date: Thu, 30 Oct 2014 09:40:24 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DBED9@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/y2Pckd8v9t8AJesW5igatXWTgbw
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 09:40:31 -0000

Nikos Mavrogiannopoulos  writes:=0A=
=0A=
>So is my understanding correct that no deployed implementation is complian=
t=0A=
>to rfc7366 so far?=0A=
=0A=
As far as I know all deployed implementations until the recent ones (NSS,=
=0A=
PolarSSL) are compliant with RFC 7366.  What they aren't compliant with is =
an=0A=
interpretation that says "MAC the ciphertext and then another 20/32 bytes o=
f=0A=
whatever follows the ciphertext", which is what the "include the MAC length=
"=0A=
interpretation seems to be doing.=0A=
=0A=
More than a year ago when the drafts were published and people implemented=
=0A=
them, there were no interop problems, no-one complained about any issues, s=
o=0A=
the draft was published as an RFC.  I'll make that point again, during the=
=0A=
entire time that it was a draft no-one informed me of any ambiguity in=0A=
interpretation or problems with interop in regard to this particular issue,=
 if=0A=
they had I would have fixed them.=0A=
=0A=
Now that it's an RFC, a new set of implementers have managed to come up wit=
h=0A=
an interpretation that, AFAICT (a) isn't in the RFC, and (b) doesn't make a=
ny=0A=
sense.  I could certainly issue a clarification, but first I'd have to=0A=
understand (a) how recent implementers are managing to come up with an=0A=
interpretation that isn't in the RFC and (b) what sort of wording to use to=
=0A=
correct this.=0A=
=0A=
Peter.=


From nobody Thu Oct 30 03:31:56 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24781AD0A9 for ; Thu, 30 Oct 2014 03:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.997
X-Spam-Level: 
X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nF3kgjs8Qn4G for ; Thu, 30 Oct 2014 03:31:53 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30BE91AD0AE for ; Thu, 30 Oct 2014 03:31:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=Vv0bCilXWqfPxrvKaAykOpPBcTSoy/DqoeHkYcc3spM=;  b=Pt4bhIv0OnJbOqDY//CtQWPJ/5EZ26jIi69JnHi168J/wf/bqRK9LhuYLPlXDzbZQchiZsXjK/q0xWSl3omgMQLwy+Shs1dodVx6AuZGuSsdNj1YgBOqikFYzxXmifmsuT9s2sN0rAkcoKQhy/TsjbRpe8p6NXQSxv5ndLxpL7U=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xjn16-0002jW-5A; Thu, 30 Oct 2014 11:31:44 +0100
Message-ID: <54521394.4040509@polarssl.org>
Date: Thu, 30 Oct 2014 11:31:48 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Peter Gutmann , "" 
References: <9A043F3CF02CD34C8E74AC1594475C739B9DBED9@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DBED9@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F9CDZUoGtcpCxf9S_BDojMbdtiQ
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 10:31:55 -0000

On 30/10/2014 10:40, Peter Gutmann wrote:
> As far as I know all deployed implementations until the recent ones (NSS,
> PolarSSL) are compliant with RFC 7366.

Just to be clear: PolarSSL and GnuTLS are not deployed, and AFAIK (from the bug
report) neither is NSS. We make sure to test interop before releasing.

> What they aren't compliant with is an
> interpretation that says "MAC the ciphertext and then another 20/32 bytes of
> whatever follows the ciphertext", which is what the "include the MAC length"
> interpretation seems to be doing.
> 
It's not what it is doing, please see my email from 10:19 today (which you might
not have noticed before posting):

https://mailarchive.ietf.org/arch/msg/tls/uCqXIwnSC1mXlbkMFxFKpOtqbRk

> More than a year ago when the drafts were published and people implemented
> them, there were no interop problems, no-one complained about any issues, so
> the draft was published as an RFC.  I'll make that point again, during the
> entire time that it was a draft no-one informed me of any ambiguity in
> interpretation or problems with interop in regard to this particular issue, if
> they had I would have fixed them.
> 
I hear you. I honestly think it's just bad luck that nobody noticed before and
the early implementers just happened to spontaneously make the same
interpretation. I guess that's why there is an errata system.

> Now that it's an RFC, a new set of implementers have managed to come up with
> an interpretation that,

I can't speak for others, but I didn't "manage to come up with". That's the most
natural interpretation of the RFC to me. I'm aware it is not what you intended
the RFC to mean, and it is not how previous implementers read it, and that's
exactly why I want the RFC to be clarified.

We're on the same side here: we all want the RFC to be deployed and used soon.
That's why we want unambiguous text that reads the same way to everyone.

> AFAICT (a) isn't in the RFC, and (b) doesn't make any
> sense. 

Regarding (b), see the email cited above. Regarding (a), please answer to the
following questions based on the text of the RFC (assuming TLS 1.2 (not DTLS,
not TLS 1.0) for the sake of simplicity; byte numbers are 0-based).

1. What should be bytes 11 and 12 of the input to the MAC function?
2. What should go on the wire as bytes 3 and 4 of the record?

My understanding of the RFC is that the answer to both of these questions is
TLSCiphertext.length. For (1), my answer is based on:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       TLSCipherText.length + // <----- bytes 11-12 of the MAC input
       IV +
       ENC(content + padding + padding_length));

For (2) it's based on:

   The overall TLS packet [2] is then:

   struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length; // <----- bytes 3-4 on the wire
          GenericBlockCipher fragment;
          opaque MAC;
          } TLSCiphertext;

So, based on the text of the RFC, am I wrong saying that those two pairs of
bytes should have the same value? If so, please tell me exactly where I'm mistaken.

If I'm not wrong here, then the eid server is, because it does not use the same
value for these two pairs of bytes.

> I could certainly issue a clarification, but first I'd have to
> understand (a) how recent implementers are managing to come up with an
> interpretation that isn't in the RFC and (b) what sort of wording to use to
> correct this.
> 
Let's first agree on the answer to the above questions, then I'll be happy to
suggest wording.

Manuel.


From nobody Thu Oct 30 03:44:26 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAACA1AD0B4 for ; Thu, 30 Oct 2014 03:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gtcthBLAbdd for ; Thu, 30 Oct 2014 03:44:23 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B0D1AD0A8 for ; Thu, 30 Oct 2014 03:44:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414665863; x=1446201863; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=en7flH4PEZjdN+XYIOsvXh0bZbeyxvJsKVJlREltIxg=; b=Vdgo48WquyLizgJ+eAqAZle59APZfcU63UoWJThmoemypoELg9O1fz7W l3NQBhANe7oGAHnLQr0pvnbXu3Dr+/m2dNQvrh/Exumckb19YUPwn9Afo NPqeK99JJMgkEm+UHvNUmZ1iVzgU2l/A/tj4RJRVgVibGnhNb5p762PcK o=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286662509"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Oct 2014 23:44:21 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 23:44:20 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/0LnVWTRqK9WIzTDCOLMsCoWZcOQ==
Date: Thu, 30 Oct 2014 10:44:19 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DBF3F@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jTw-0_2dS-3nouFcax9jF7RWa2E
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 10:44:24 -0000

Manuel P=E9gouri=E9-Gonnard  writes:=0A=
=0A=
>Sure, I'd never think of doing that. But I can certainly tell my code to=
=0A=
>compute=0A=
>=0A=
>  MAC_k( seq_num + type + version + length + encrypted_stuff )=0A=
>=0A=
>with length !=3D length_of(encrypted_stuff). After all, for the MAC functi=
on,=0A=
>what we call "length" is just two meaningless bytes.=0A=
=0A=
Oh, so the issue isn't that you're MAC'ing extra stuff that isn't there, bu=
t=0A=
that you're using a length value that includes stuff that isn't MAC'd?  In=
=0A=
other words in the above 'length' isn't 'length of encrypted_stuff that=0A=
follows the length value' but 'length of encrypted_stuff that follows the=
=0A=
length value + length of MAC'?=0A=
=0A=
Peter.=


From nobody Thu Oct 30 04:12:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373DF1AD0B8 for ; Thu, 30 Oct 2014 04:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqQYTKc1nVx9 for ; Thu, 30 Oct 2014 04:12:13 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFCF1AD09D for ; Thu, 30 Oct 2014 04:12:13 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 8705E8187B; Thu, 30 Oct 2014 13:12:10 +0200 (EET)
Date: Thu, 30 Oct 2014 13:12:10 +0200
From: Ilari Liusvaara 
To: Peter Gutmann 
Message-ID: <20141030111210.GA15345@LK-Perkele-VII>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DBED9@uxcn10-5.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DBED9@uxcn10-5.UoA.auckland.ac.nz>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BQBFelIsMhBYQMA3iHS0LKhn9nI
Cc: "" 
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 11:12:16 -0000

On Thu, Oct 30, 2014 at 09:40:24AM +0000, Peter Gutmann wrote:
> Nikos Mavrogiannopoulos  writes:
> 
> >So is my understanding correct that no deployed implementation is compliant
> >to rfc7366 so far?
> 
> Now that it's an RFC, a new set of implementers have managed to come up with
> an interpretation that, AFAICT (a) isn't in the RFC, and (b) doesn't make any
> sense.  I could certainly issue a clarification, but first I'd have to
> understand (a) how recent implementers are managing to come up with an
> interpretation that isn't in the RFC and (b) what sort of wording to use to
> correct this.

I read relevant parts of RFC7366 and RFC5246. 

I got (perhaps weird) interpretation that this extension truly pulls the
MAC off ciphertext fragment.

Thus, the length field on _wire_ does _not_ include the MAC, and the
MAC'd data is what is on wire, bit for bit.


E.g. 14-byte application payload, minimal padding, AES-CBC, HMAC-SHA1,
TLS v1.2: 32 bytes, regardless of MAC truncation (whereas normally it
would be 52 for full and e.g. 48 for 16-byte truncated MAC).


What that sort of thing does to "middleboxes" that for some reason
parse the TLS PDU stream could be somewhat... interesting.


-Ilari


From nobody Thu Oct 30 04:34:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF82B1AD0C4 for ; Thu, 30 Oct 2014 04:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXg9W5dVT3Y0 for ; Thu, 30 Oct 2014 04:34:39 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434FC1AD0C0 for ; Thu, 30 Oct 2014 04:34:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=7vdLR+5XJ+vJ22a26zFgcmniviD3S8OO+6mDff4XCqY=;  b=At39MeiEX1woXv/w0642/36LjKYlZFKnm+k8y1XfHjAwuAtAwWOBZsSd9pSCRfg/HO2skepqjlwfOU6ET4uvw2dEz46Z/9xV/n9V2qae/574hydgrKTi9otbAz7EyiMzOxL7X7bX8S4sfnBBv/tnB4PrhvhW1aAHOHR+YLDfBD8=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xjnzq-0002pT-DD; Thu, 30 Oct 2014 12:34:30 +0100
Message-ID: <5452224A.9030202@polarssl.org>
Date: Thu, 30 Oct 2014 12:34:34 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ilari Liusvaara ,  Peter Gutmann 
References: <9A043F3CF02CD34C8E74AC1594475C739B9DBED9@uxcn10-5.UoA.auckland.ac.nz> <20141030111210.GA15345@LK-Perkele-VII>
In-Reply-To: <20141030111210.GA15345@LK-Perkele-VII>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-NEn001ujKX3g9qc7Zlh6sLyzbM
Cc: "" 
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 11:34:43 -0000

On 30/10/2014 12:12, Ilari Liusvaara wrote:
> Thus, the length field on _wire_ does _not_ include the MAC, and the
> MAC'd data is what is on wire, bit for bit.
> 
I think that's one possible way to read the RFC indeed. I'll just repeat what
Nikos said in [1]: this is _not_ what the eid server does.

https://www.ietf.org/mail-archive/web/tls/current/msg14345.html

> E.g. 14-byte application payload, minimal padding, AES-CBC, HMAC-SHA1,
> TLS v1.2: 32 bytes, regardless of MAC truncation (whereas normally it
> would be 52 for full and e.g. 48 for 16-byte truncated MAC).
> 
And in this scenario, the eid server puts 52 (ie 00 34) on the wire. As does
every other implementation I know of.

Just to (try and) make sure the behaviour of the implementations discuss is
clear to everyone, the only difference between the two groups of implementation
I know of is that, in your example (thanks for making things concrete) is:

MAC( seq_num, type, version, 00 20, encrypted_stuff ) // eid, openssl

vs:

MAC( seq_num, type, version, 00 34, encrypted_stuff ) // nss, gnutls, polarssl

> What that sort of thing does to "middleboxes" that for some reason
> parse the TLS PDU stream could be somewhat... interesting.
> 
I think so. Even without considering middleboxes, this doesn't sound right, and
that's probably why no implementation does that, thought I agree that's one of
the conclusions that can be logically reached by strictly interpreting the RFC.

Manuel.


From nobody Thu Oct 30 04:42:06 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947231AD0C9 for ; Thu, 30 Oct 2014 04:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsZr-4QXoPBU for ; Thu, 30 Oct 2014 04:41:56 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742161AD0CD for ; Thu, 30 Oct 2014 04:41:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=AiVqnis3iyZjUJDIabNjQ/XSDsPQqCvLAcnUyVEsjig=;  b=aAd4zARioRrxBrAACq2Dld/OSa0iZVJkKt5D4DFnAXN9u3mPwQPFPPC4PoKAjNkf6a4FPUUvJ9MH81xkVZJfFR8gKAeDensuvnyBtLNrQG7gAjwQa1R9rI0Dr+bCR1AVYWXPJmdEAzaB/K0StuvnTJwtrjI5mdfyDOMQjdGnPqI=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xjo6u-0002qC-HB; Thu, 30 Oct 2014 12:41:48 +0100
Message-ID: <54522401.8010100@polarssl.org>
Date: Thu, 30 Oct 2014 12:41:53 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Peter Gutmann , "" 
References: <9A043F3CF02CD34C8E74AC1594475C739B9DBF3F@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DBF3F@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gp_riJiEkctDziiqXPELBdCo_UU
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 11:42:00 -0000

On 30/10/2014 11:44, Peter Gutmann wrote:
> Manuel Pégourié-Gonnard  writes:
> 
>> Sure, I'd never think of doing that. But I can certainly tell my code to
>> compute
>>
>>  MAC_k( seq_num + type + version + length + encrypted_stuff )
>>
>> with length != length_of(encrypted_stuff). After all, for the MAC function,
>> what we call "length" is just two meaningless bytes.
> 
> Oh, so the issue isn't that you're MAC'ing extra stuff that isn't there, but
> that you're using a length value that includes stuff that isn't MAC'd?  In
> other words in the above 'length' isn't 'length of encrypted_stuff that
> follows the length value' but 'length of encrypted_stuff that follows the
> length value + length of MAC'?
> 
Precisely. It looks like we're making progress in undertanding each other.

(As a side point (since I'm not arguing that what I'm doing is The Right Thing
do to, rather that it's unclear from the text of the RFC), both options look
completely equivalent to me from a security point of view, since one needs to
know the length of the MAC to check it, anyway.)

Manuel.


From nobody Thu Oct 30 04:50:25 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6471AD0D7 for ; Thu, 30 Oct 2014 04:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK947y6zGg5l for ; Thu, 30 Oct 2014 04:50:22 -0700 (PDT)
Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE9E1AD0CD for ; Thu, 30 Oct 2014 04:50:21 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id x19so5023635ier.16 for ; Thu, 30 Oct 2014 04:50:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4lewjsBZVXxtFW9deoBsVBGEomcRA/gI5d5VyNh/znM=; b=PVwiUdY0/lzR3xsSjF0WYozPTZ04fECBAo6XWdb3vNpYS6uv7WbvkMCh86puA40oP/ QF2u6qjXvpQpcWuNqmaSXyWxZ4dhYrQxhrAjRTG8AJ4VY/alZ4Wnl7IcI/akM8FyYVVt FBkuKyrFcTRcUHFoTHxy8gRYVHsx5VCld+oHDRgz9Z1O39eW9FvXwJiIyi22Koe76I55 W7UGrMhMwwAigBN7NOK2Ecp6B+OT36nDMEejHdZl8dbg9ec1XxCzfONDjFE8LEaTvPB2 3t47WytlQ8rq5E2jTn9mjTwPgJNEjdpyRJBRckydh9hjMWg9AAQ8/+ICpTWguKjncjmp V3gA==
X-Gm-Message-State: ALoCoQkqL/3Q1GJ2dqCQXkPdLHYumF7qmVqAMuH5yTnGZ1eleeJU02aRxuwYAbXikz3F6+mrAGQx
MIME-Version: 1.0
X-Received: by 10.50.61.209 with SMTP id s17mr18167577igr.34.1414669821203; Thu, 30 Oct 2014 04:50:21 -0700 (PDT)
Received: by 10.107.132.99 with HTTP; Thu, 30 Oct 2014 04:50:20 -0700 (PDT)
Received: by 10.107.132.99 with HTTP; Thu, 30 Oct 2014 04:50:20 -0700 (PDT)
In-Reply-To: <1414071393.2511.16.camel@dhcp-2-127.brq.redhat.com>
References: <1414071393.2511.16.camel@dhcp-2-127.brq.redhat.com>
Date: Thu, 30 Oct 2014 12:50:20 +0100
Message-ID: 
From: Christian Kahlo 
To: Nikos Mavrogiannopoulos 
Content-Type: multipart/alternative; boundary=047d7bdc14e62af4f40506a27c52
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2oIng1ufNOPfRoTJd_cxmHKV8k8
Cc: tls@ietf.org
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 11:50:24 -0000

--047d7bdc14e62af4f40506a27c52
Content-Type: text/plain; charset=UTF-8

Uh, I've got to fix that asap. Thanks for the reminder. I'll get back to
you / the list later. This is sent from my phone.

Cheers,
Christian
 Am 23.10.2014 15:37 schrieb "Nikos Mavrogiannopoulos" :

> Hello,
>  Is there some public server implementing rfc7366? At some point the
> server at eid.vx4.net was sent as one, but it doesn't seem to implement
> the protocol in the published rfc (the NSS people seem to have noticed
> that [0], and my tests agree).
>
> regards,
> Nikos
>
> [0]. https://bugzilla.mozilla.org/show_bug.cgi?id=972145
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7bdc14e62af4f40506a27c52
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Uh, I've got to fix that asap. Thanks for the reminder. =
I'll get back to you / the list later. This is sent from my phone. 


Cheers,

Christian 




Am 23.10.2014 15:37 schrieb "Nikos Mavrogia=
nnopoulos" <nmav@redhat.com&=
gt;:
Hello,

=C2=A0Is there some public server implementing rfc7366? At some point the
server at eid.vx4.net =
was sent as one, but it doesn't seem to implement

the protocol in the published rfc (the NSS people seem to have noticed

that [0], and my tests agree).



regards,

Nikos



[0]. https://bugzilla.mozilla.org/show_bug.cgi?id=3D972145





_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls




--047d7bdc14e62af4f40506a27c52--


From nobody Thu Oct 30 05:25:00 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3611B1A0007 for ; Thu, 30 Oct 2014 05:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YStFwu4_Yq2h for ; Thu, 30 Oct 2014 05:24:53 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC581A0011 for ; Thu, 30 Oct 2014 05:24:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414671893; x=1446207893; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=OqUwmU0cNiWAvBv63QW3VyVFpwNChPihSUYvHe3Y3aU=; b=m8JRURjL8fnI19Db6jnLLchriB39YPrgbC9LlWIsKfSLkM6zY6BGQhtV 0F2qM09MdIKFB6O3EOWwfnv9Xfp876MOZXLAq8rLY0Q31sMIMn6jSPJ/e /GVXfJ69PBOWgunwmwApqXNLDe1fy0/d/W8g+fAMYIEI9MFwnTXsQhAnU c=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286675158"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 31 Oct 2014 01:24:50 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Fri, 31 Oct 2014 01:24:48 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/0PH582LCf7xQxTNC0nCvzNaQeVA==
Date: Thu, 30 Oct 2014 12:24:47 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DBFE4@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4mhAQ_UwHX7bp3JhIllpGPf4_us
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 12:24:58 -0000

Manuel P=E9gouri=E9-Gonnard  writes:=0A=
>On 30/10/2014 11:44, Peter Gutmann wrote:=0A=
>> Oh, so the issue isn't that you're MAC'ing extra stuff that isn't there,=
 but=0A=
>> that you're using a length value that includes stuff that isn't MAC'd?  =
In=0A=
>> other words in the above 'length' isn't 'length of encrypted_stuff that=
=0A=
>> follows the length value' but 'length of encrypted_stuff that follows th=
e=0A=
>> length value + length of MAC'?=0A=
>Precisely. It looks like we're making progress in undertanding each other.=
=0A=
=0A=
OK, so I'll try and summarise this, for:=0A=
=0A=
struct {=0A=
       ContentType type;=0A=
       ProtocolVersion version;=0A=
       uint16 length;=0A=
       GenericBlockCipher fragment;=0A=
       opaque MAC;=0A=
       } TLSCiphertext;=0A=
=0A=
what goes on the wire for the 'length' field is the overall length of=0A=
everything that follows, i.e. the ciphertext fragment length plus MAC lengt=
h.=0A=
=0A=
What gets MAC'd is something like:=0A=
=0A=
    MAC(MAC_write_key, seq_num +=0A=
                       TLSCompressed.type +=0A=
                       TLSCompressed.version +=0A=
                       TLSCompressed.length +=0A=
                       GenericBlockCipher.fragment);=0A=
=0A=
(I say "something like" because RFC 5246 doesn't make this explicit, it ref=
ers=0A=
back to section 6.2.3.1 which is for null or generic stream ciphers and use=
s=0A=
TLSCompressed.fragment when it should be TLSCiphertext.fragment).=0A=
=0A=
Since the MAC value isn't part of the data that's MAC'd, its length isn't=
=0A=
included in the MAC calculation.=0A=
=0A=
Now the other interpretation, that more recent implementations are using, i=
s=0A=
that what gets MAC'd is the length of GenericBlockCipher.fragment plus the=
=0A=
length of MAC[SecurityParameters.mac_length], which is the length value tha=
t=0A=
goes on the wire.=0A=
=0A=
Arguments could be made that either interpretation is valid... it could be=
=0A=
just a case of saying "who will be least inconvenienced by switching over?"=
.=0A=
In any case it points to what's required for issuing a clarification to the=
=0A=
text.=0A=
=0A=
Peter.=


From nobody Thu Oct 30 05:25:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950601A0040 for ; Thu, 30 Oct 2014 05:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGuF0sjJfoX7 for ; Thu, 30 Oct 2014 05:25:14 -0700 (PDT)
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02AAF1A0029 for ; Thu, 30 Oct 2014 05:25:13 -0700 (PDT)
Received: by mail-lb0-f180.google.com with SMTP id z12so4256083lbi.11 for ; Thu, 30 Oct 2014 05:25:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:reply-to:from:to:cc:references :in-reply-to:subject:date:organization:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=+tYDv8r1WocQYB6ad44vGhQu/wyz1E+xiR5MRQm3YAc=; b=GvH+YzB0FW2tUO+9pMyhZMdZoVGH1h/ech2LrV34yUn3IIEYlsdoSB/axwoUbIIusF FS20vCZTrWTuyAYNvqQCVFWE5qoSCAPU7i++xy9VmDpAYzpEKBPgF78eHqspk15ZGfed mhRpbX89huPhZc63c8J/cm1IyObzSwEFOhSxSmDjSDlsRVASPlfw/aAO9zWe7M/q8AHa OALN7yV54PFp1a7qFl1oENWNWo+z7QseNMBmQKdp6j6K4vATTbJMj0Ibv11UFNdEscbf T4lHfMvEJJfRlx/5vCqKauwZsOMlCXNldC4eEZG0RCj8wkxBLduzTCl5V576eNxtDjno DKJA==
X-Gm-Message-State: ALoCoQleq9cJbScToLgvjoJya1rPPq14d93R+ASXsb1Voz9zsMTiWmaTnvkPMYy6I9SYFn9Qq7U3
X-Received: by 10.152.228.140 with SMTP id si12mr18508416lac.66.1414671912157;  Thu, 30 Oct 2014 05:25:12 -0700 (PDT)
Received: from THINK2 ([82.119.170.75]) by mx.google.com with ESMTPSA id m1sm3139721lbt.22.2014.10.30.05.25.10 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Oct 2014 05:25:11 -0700 (PDT)
Message-ID: <54522e27.6143700a.22d4.ffffad31@mx.google.com>
X-Google-Original-Message-ID: <000001cff43c$8cb3c340$a61b49c0$@kahlo@ageto.net>
From: "Christian Kahlo" 
To: "'Peter Gutmann'" , , =?iso-8859-1?Q?'Manuel_P=E9gouri=E9-Gonnard'?= 
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB261@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB261@uxcn10-5.UoA.auckland.ac.nz>
Date: Thu, 30 Oct 2014 13:25:09 +0100
Organization: AGETO Innovation GmbH
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac/zezXuWeYDktXrQwW4s6eeqLonSgAwMqig
Content-Language: de
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Bag07kcjgcqAiVDNf5eTP0qcG6s
Cc: npa@ageto.net
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: c.kahlo@ageto.net
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 12:25:22 -0000

Hi there,

I didn't change anything in the record structure or the handshake
behaviour. The only change is the new code point assignment for
the extension.

But as stated before I'll have a look in the final RFC and compare
it to the currently deployed implementation.

It would help to get handshake logs to see what happened on the
other end.

It is also possible to activate full debug mode and check for
interop issues.

Sorry, this didn't came to my attention until now. But it's
high prio now.

Best regards,
Christian

> -----Urspr=FCngliche Nachricht-----
> Von: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]
> Gesendet: Mittwoch, 29. Oktober 2014 14:21
> An: ; Manuel P=E9gouri=E9-Gonnard; Christian Kahlo
> Betreff: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
>=20
> Manuel P=E9gouri=E9-Gonnard  writes:
>=20
> >My implementation does not interoperate with the one at eid.wx4.net
> >either, when I enable EtM (fails with a bad_record_mac alert).
>=20
> So what are people doing to get this?  Ages ago when the draft was
> first published a bunch of implementations interop'd with this, so I
> wonder what's changed?
>=20
> Peter.


From nobody Thu Oct 30 05:56:31 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19FE1A0054 for ; Thu, 30 Oct 2014 05:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.997
X-Spam-Level: 
X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0myAIqpcRGd4 for ; Thu, 30 Oct 2014 05:56:29 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69441A000F for ; Thu, 30 Oct 2014 05:56:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=SlkLyiSCEKlHCwAqr4S6lz/T4fQM5dqDoexohcvTKD0=;  b=HeHb75hTiz05cN4VaT4dnJBwZOd7d/sISqz//H5U2iDsWBeq+XYCQsTrnVuH0s2i0YRJNazDTz+I1Hj0QO9KNVdcgEWTGRluy6ByljmFlzINmDw/OfxTvDeueBFPXDBWJVx73aD/f8RxE9t4++NOhhhZj9wQul5B/XOhbY3arjw=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XjpH0-0002vc-Tr; Thu, 30 Oct 2014 13:56:19 +0100
Message-ID: <54523577.3000508@polarssl.org>
Date: Thu, 30 Oct 2014 13:56:23 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Peter Gutmann , "" 
References: <9A043F3CF02CD34C8E74AC1594475C739B9DBFE4@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DBFE4@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-xzMEYwhwATxi8sR_hyW_zkHcoE
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 12:56:31 -0000

On 30/10/2014 13:24, Peter Gutmann wrote:
> Manuel Pégourié-Gonnard  writes:
>> On 30/10/2014 11:44, Peter Gutmann wrote:
>>> Oh, so the issue isn't that you're MAC'ing extra stuff that isn't there, but
>>> that you're using a length value that includes stuff that isn't MAC'd?  In
>>> other words in the above 'length' isn't 'length of encrypted_stuff that
>>> follows the length value' but 'length of encrypted_stuff that follows the
>>> length value + length of MAC'?
>> Precisely. It looks like we're making progress in undertanding each other.
> 
> OK, so I'll try and summarise this, for:
> 
> struct {
>        ContentType type;
>        ProtocolVersion version;
>        uint16 length;
>        GenericBlockCipher fragment;
>        opaque MAC;
>        } TLSCiphertext;
> 
> what goes on the wire for the 'length' field is the overall length of
> everything that follows, i.e. the ciphertext fragment length plus MAC length.
> 
Ok. I think all implementations so far agree on this point.

> What gets MAC'd is something like:
> 
>     MAC(MAC_write_key, seq_num +
>                        TLSCompressed.type +
>                        TLSCompressed.version +
>                        TLSCompressed.length +
>                        GenericBlockCipher.fragment);
> 
> (I say "something like" because RFC 5246 doesn't make this explicit, it refers
> back to section 6.2.3.1 which is for null or generic stream ciphers and uses
> TLSCompressed.fragment when it should be TLSCiphertext.fragment).
> 
Are you refering the "normal" (MtE) case or the EtM case here? I'm confused. in
the MtE case, what's MAC'ed is indeed TLSCompressed.fragment. Anyways, what
matters is the text in RFC 7366 about MAC computation, which uses
TLSCiphertext.length.

> Since the MAC value isn't part of the data that's MAC'd, its length isn't
> included in the MAC calculation.
> 
I understand this reasoning and it certainly makes sense, I'm not discussing
that. But that means that when you write TLSCiphertext.length at the beginning
of page 3 in:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       TLSCipherText.length +
       IV +
       ENC(content + padding + padding_length));

you mean something different from the length field of the TLSCiphertext
structure just two paragraphs below. Which I find rather confusing.

> Now the other interpretation, that more recent implementations are using, is
> that what gets MAC'd is the length of GenericBlockCipher.fragment plus the
> length of MAC[SecurityParameters.mac_length], which is the length value that
> goes on the wire.
> 
Right. This is supported by the fact that both (what get's MAC'd and what goes
in the wire) are written as TLSCiphertext.length in the RFC.

> Arguments could be made that either interpretation is valid... it could be
> just a case of saying "who will be least inconvenienced by switching over?".
> In any case it points to what's required for issuing a clarification to the
> text.
> 
Again, I have no preference on which interpretation is chosen, as long as there
remains only one arguably valid way to interpret the text.

If you want to go the same way as the eid server (which is reasonnable IMO as it
is deployed) I'd suggest changing from

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       TLSCipherText.length +
       IV +
       ENC(content + padding + padding_length));

to

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of ENC(content + padding + padding_length) +
       IV +
       ENC(content + padding + padding_length));

    where the length is encoded as two bytes in the usual way.

This avoids any ambiguity related to TLSCiphertext.xxx and how its definition
should or should not be adapted from the one in RFC 5246.

To be extra sure that people don't get confused about what goes on the wire
(even though all implementations so far agreed on this point), you could also change

   This is identical to the existing TLS/DTLS layout, with the only
   difference being that the MAC value is moved outside the encrypted
   data.

to add:

   This is identical to the existing TLS/DTLS layout, with the only
   differences being that the MAC value is moved outside the encrypted
   data and length is now sum of the length of fragment and the length
   of the MAC.

(or something to that effect).

Manuel.


From nobody Thu Oct 30 06:07:00 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D691AD160 for ; Thu, 30 Oct 2014 06:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fReySCF4D19R for ; Thu, 30 Oct 2014 06:06:55 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57421AD0D7 for ; Thu, 30 Oct 2014 06:06:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414674411; x=1446210411; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=RYLEpTY0aPhfZfv3fRrkd7WGiQF7Bf3PVYOklKmaNXQ=; b=h9grN04RjmDw4Z9fHv+bI6oQDEtSKpfc+EGcOYvvppyUu8WArlR4MKBa Zv/PKA9YQVWY8BdRZ3LDij6tMuYrEqKpetPodQbNDf/GMzx9d+ZKF73A9 TB6HKoA7zGpp7CA9it4ePyPY16Tyjjn49quf5ccYUTxfNVp7NTcAd+sTJ 0=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286679206"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 31 Oct 2014 02:06:49 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 31 Oct 2014 02:06:48 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: AW: [TLS] rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/0QlyClWW7Q6CgQVidvuiE5f8+/w==
Date: Thu, 30 Oct 2014 13:06:47 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DC04D@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ahM3PI8omoh7ssqxGHwo9-D91OM
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 13:06:57 -0000

Christian Kahlo  writes:=0A=
=0A=
>But as stated before I'll have a look in the final RFC and compare it to t=
he=0A=
>currently deployed implementation.=0A=
=0A=
See the more recent messages about this though, there are two possible=0A=
interpretations, both equally valid, so don't go changing things just yet :=
-).=0A=
=0A=
Peter.=


From nobody Thu Oct 30 06:11:49 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF361AD0BC for ; Thu, 30 Oct 2014 06:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr-YRIuQZCeg for ; Thu, 30 Oct 2014 06:11:38 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89C81AD1C3 for ; Thu, 30 Oct 2014 06:11:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=KM6u97+PreyLAoWZsE2n6zMQPb1mJhv1ygqVkTi9KB0=;  b=GxSG0q+MlylfYfQAaLoFvScY6mGfM6nc4k1f9S7TF0bsyiegmePRWQNCnyN57f6FJkXtqfuJRX5Z8/WNWyzG1rhekJo+3iDqcaj+AqWU3pQXlZJueZWCX5IQtTSTmh6yueptIJDmqlFHMYknEiyT+N8K4wnOr1UTv80NheqHUAs=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XjpVd-0002wu-QC; Thu, 30 Oct 2014 14:11:26 +0100
Message-ID: <54523902.2050606@polarssl.org>
Date: Thu, 30 Oct 2014 14:11:30 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: c.kahlo@ageto.net, 'Peter Gutmann' ,  tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB261@uxcn10-5.UoA.auckland.ac.nz> <54522e27.6143700a.22d4.ffffad31@mx.google.com>
In-Reply-To: <54522e27.6143700a.22d4.ffffad31@mx.google.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-TkBfTswdE4_hCK51QYtpt0S9-8
Cc: npa@ageto.net
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 13:11:40 -0000

Hi Christian,

and thanks for joining the discussion.

On 30/10/2014 13:25, Christian Kahlo wrote:
> It would help to get handshake logs to see what happened on the
> other end.
> 
As someone who has first written an incompatible implementation and then changed
it to be compatible, I think what happened is clear enough.

Oh, and I see while writing that Peter has been faster than me on the second
thing I wanted to tell: it's probably better to clarify the RFC first and only
later change the implementations that need to be changed to match the clarified
version.

Manuel.


From nobody Thu Oct 30 06:40:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A113F1A0053 for ; Thu, 30 Oct 2014 06:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Level: 
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIF0mUB__8eU for ; Thu, 30 Oct 2014 06:40:19 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC8C1AD255 for ; Thu, 30 Oct 2014 06:40:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414676420; x=1446212420; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=UHp5y2sZh/eKSiesicq81d/WKaYYI/YaF56Yea8m5BE=; b=DriO7Foc+ZaHX44wPOO6qsASbcfCSdGq8iQxAhHLkX3LQePi2ZC3gKtc vIZYw8h6mNgE7ib3nH3eAHmRs/gFudvOyv1oXSE6g0phlal0gZGTtvEOI Voe0RPJReg02UuZVvWKwjQ7tjU6j3zdi9WtNwTrM3vVbnFiDXjS5ksHGr I=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286681356"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 31 Oct 2014 02:40:14 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Fri, 31 Oct 2014 02:40:12 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/0RwccXPTVUB6lQEmHOtzHHp8uqg==
Date: Thu, 30 Oct 2014 13:40:11 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DC0AA@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 13:40:21 -0000

Manuel P=E9gouri=E9-Gonnard  writes:=0A=
=0A=
>Are you refering the "normal" (MtE) case or the EtM case here? =0A=
=0A=
The EtM case.  In the MtE case what gets MAC'd is the plaintext, i.e. only=
=0A=
TLSCompressed.fragment.  In the EtM case what gets MAC'd is the ciphertext=
=0A=
including padding and other stuff, so GenericBlockCipher.fragment.=0A=
=0A=
>This is supported by the fact that both (what get's MAC'd and what goes in=
=0A=
>the wire) are written as TLSCiphertext.length in the RFC.=0A=
=0A=
The correct notation to use is quite confusing, intuitively you can say "th=
e=0A=
length used in the MAC calculation is the length of the data that gets MAC'=
d",=0A=
but specifying it in notation isn't so easy, it's the length of the padded=
=0A=
encrypted TLSCompressed value as well as the length of the IV if TLS 1.1 or=
=0A=
newer is used.  If there's some clear way of saying that that, say, at leas=
t=0A=
three different people can agree on I'll use it.=0A=
=0A=
>Again, I have no preference on which interpretation is chosen, as long as=
=0A=
>there remains only one arguably valid way to interpret the text.=0A=
=0A=
Sure.=0A=
=0A=
>   MAC(MAC_write_key, seq_num +=0A=
>       TLSCipherText.type +=0A=
>       TLSCipherText.version +=0A=
>       length of ENC(content + padding + padding_length) +=0A=
>       IV +=0A=
>       ENC(content + padding + padding_length));=0A=
>=0A=
>    where the length is encoded as two bytes in the usual way.=0A=
=0A=
That's still not quite right though because it excludes the length of the I=
V=0A=
when it's present in TLS 1.1+ (see above).  The intent of using=0A=
TLSCipherText.length was to accommodate the different protocol-version-=0A=
dependent options.=0A=
=0A=
What about defining it the other way round, instead of saying "the length u=
sed=0A=
is this and that and sometimes something else", say "the length value used =
for=0A=
the MAC computation is the length as encoded on the wire minus=0A=
SecurityParameters.mac_length, since the MAC value is not included in the M=
AC=0A=
computation"?  So perhaps:=0A=
=0A=
  Note that the value of the 'uint16 length' field in the TLSCiphertext rec=
ord=0A=
  differs from the length value used in the MAC calculation, since the=0A=
  TLSCiphertext record contains both the ciphtertext and the MAC, while the=
=0A=
  MAC calculation is performed only over the ciphertext.  So the length val=
ue=0A=
  encoded in the TLSCiphertext record is 'length' while the length value us=
ed=0A=
  in the MAC calculation is 'length - SecurityParameters.mac_length'.=0A=
=0A=
Peter.=


From nobody Thu Oct 30 06:45:30 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC9B1AD1D5 for ; Thu, 30 Oct 2014 06:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level: 
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-wFAfZ3qtR3 for ; Thu, 30 Oct 2014 06:45:26 -0700 (PDT)
Received: from vsp7.ballou.se (vsp7.ballou.se [91.189.40.103]) by ietfa.amsl.com (Postfix) with SMTP id 3B1121AD1A3 for ; Thu, 30 Oct 2014 06:45:25 -0700 (PDT)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp7.ballou.se (Halon Mail Gateway) with ESMTP for ; Thu, 30 Oct 2014 14:45:22 +0100 (CET)
Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 7410A1DE4C for ; Thu, 30 Oct 2014 14:45:22 +0100 (CET)
Message-ID: <545240DD.9010803@streamsec.se>
Date: Thu, 30 Oct 2014 14:45:01 +0100
From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C739B9DC0AA@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DC0AA@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zooD8SCjA8A8EZvoDCt8MZUZ-eg
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: henrick@streamsec.se
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 13:45:28 -0000

On 2014-10-30 14:40, Peter Gutmann wrote:
> The correct notation to use is quite confusing, intuitively you can say "the
> length used in the MAC calculation is the length of the data that gets MAC'd",
> but specifying it in notation isn't so easy, it's the length of the padded
> encrypted TLSCompressed value as well as the length of the IV if TLS 1.1 or
> newer is used.  If there's some clear way of saying that that, say, at least
> three different people can agree on I'll use it.

Would it be overkill to define a new TLSIntermediaryCiphertext record type?


From nobody Thu Oct 30 06:57:31 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6321F1AD38E for ; Thu, 30 Oct 2014 06:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.997
X-Spam-Level: 
X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6kzNMN6D1ya for ; Thu, 30 Oct 2014 06:57:24 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0703B1AD38C for ; Thu, 30 Oct 2014 06:57:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=yrWX4iNdta7lCAis6A+QoVbME2/TlQMuefrd/18ahOA=;  b=O+GXBXnaVe2/4P8lRmClLqPonk9gq/v6waGPknbzZt3sJYrEQ4QYHp8JwHqyzIWVnvA8RqfVowFbQ1zf2zfUk+bgqAfsj0Z7/GtKumbBIthUBDjX3Fv2g+9Ln+Gc8E87+b+fB/bdRkiCbhs3MaD174Bvyk/COcl3nZAWw1xxxgM=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XjqDz-000303-Di; Thu, 30 Oct 2014 14:57:15 +0100
Message-ID: <545243C0.2000802@polarssl.org>
Date: Thu, 30 Oct 2014 14:57:20 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Peter Gutmann , "" 
References: <9A043F3CF02CD34C8E74AC1594475C739B9DC0AA@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DC0AA@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zYBKe9L9n3tNZ_SBWn77ubLzNPs
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 13:57:26 -0000

On 30/10/2014 14:40, Peter Gutmann wrote:
> Manuel Pégourié-Gonnard  writes:
> 
>> Are you refering the "normal" (MtE) case or the EtM case here? 
> 
> The EtM case.  In the MtE case what gets MAC'd is the plaintext, i.e. only
> TLSCompressed.fragment.  In the EtM case what gets MAC'd is the ciphertext
> including padding and other stuff, so GenericBlockCipher.fragment.
> 
Ok. I'm not sure if it's a good idea to use GenericBlockCipher.fragment to
denote this. GenericBlockCipher is a struct defined with a different meaning in
RFC 5246.

>>   MAC(MAC_write_key, seq_num +
>>       TLSCipherText.type +
>>       TLSCipherText.version +
>>       length of ENC(content + padding + padding_length) +
>>       IV +
>>       ENC(content + padding + padding_length));
>>
>>    where the length is encoded as two bytes in the usual way.
> 
> That's still not quite right though because it excludes the length of the IV
> when it's present in TLS 1.1+ (see above).

You're right obviously. So I change my suggestion to:

           In TLS [2] notation, the MAC calculation for TLS 1.0 without
   the explicit Initialization Vector (IV) is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (ENC(content + padding + padding_length)) +
       ENC(content + padding + padding_length));

   and for TLS 1.1 and greater with an explicit IV is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (IV + ENC(content + padding + padding_length)) +
       IV +
       ENC(content + padding + padding_length));

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (IV + ENC(content + padding + padding_length)) +
       IV +
       ENC(content + padding + padding_length));

    where the length is encoded as two bytes in the usual way.

since the text is already distinguishing between the two.

>  The intent of using
> TLSCipherText.length was to accommodate the different protocol-version-
> dependent options.
> 
Ok. I'm afraid here we have a conflict between being concise and being
unambiguous, and I'd err on the side of unambiguous.

> What about defining it the other way round, instead of saying "the length used
> is this and that and sometimes something else", say "the length value used for
> the MAC computation is the length as encoded on the wire minus
> SecurityParameters.mac_length, since the MAC value is not included in the MAC
> computation"?

Sounds like a good idea, but there is the minor problem that currently the
length on the wire is defined after the MAC computation is defined.

>  So perhaps:
> 
>   Note that the value of the 'uint16 length' field in the TLSCiphertext record
>   differs from the length value used in the MAC calculation, since the
>   TLSCiphertext record contains both the ciphtertext and the MAC, while the
>   MAC calculation is performed only over the ciphertext.  So the length value
>   encoded in the TLSCiphertext record is 'length' while the length value used
>   in the MAC calculation is 'length - SecurityParameters.mac_length'.
> 
That sounds pretty clear to me. A belt-and-braces approach could even combine
this paragraph with my above suggestion...

Manuel.


From nobody Thu Oct 30 07:47:37 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154101AD440 for ; Thu, 30 Oct 2014 07:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-_Th9izVC74 for ; Thu, 30 Oct 2014 07:47:34 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9219D1AD443 for ; Thu, 30 Oct 2014 07:47:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim;  h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=kKqbDedBhIh3dyLKcQB1g6HmnVE1gUlDKJOB7QkcfLI=;  b=N5DUbdGeEb85hG2oCKV9ltj2qlU9ldl0t1AtEMq/TwyyiuiO1yxvgiwYQAfVRGJSDbDqHJ05u9fX8YYF4wJ6484TsSX7Bsi5GGqCa/KB8xH7uPWuzWYy+DPQKNav5ne2ET3J4Slcr9pDHHm1JA7sR6Frm6l6ueT1MYSV8TgFbFk=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xjr0Y-00033C-K2; Thu, 30 Oct 2014 15:47:27 +0100
Message-ID: <54524F83.3010405@polarssl.org>
Date: Thu, 30 Oct 2014 15:47:31 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: henrick@streamsec.se, tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C739B9DC0AA@uxcn10-5.UoA.auckland.ac.nz> <545240DD.9010803@streamsec.se>
In-Reply-To: <545240DD.9010803@streamsec.se>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ejD3iqiaUAqhDh3VdLlRlf188Ug
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 14:47:36 -0000

On 30/10/2014 14:45, Henrick Hellström wrote:
> On 2014-10-30 14:40, Peter Gutmann wrote:
>> The correct notation to use is quite confusing, intuitively you can say "the
>> length used in the MAC calculation is the length of the data that gets MAC'd",
>> but specifying it in notation isn't so easy, it's the length of the padded
>> encrypted TLSCompressed value as well as the length of the IV if TLS 1.1 or
>> newer is used.  If there's some clear way of saying that that, say, at least
>> three different people can agree on I'll use it.
> 
> Would it be overkill to define a new TLSIntermediaryCiphertext record type?
> 
Another (related) idea: explicitly change the definition of
GenericBlockCipher when EtM is in use (which is already implicitly done
at some point). Eg (unchanged text is indicated by a | in the margin,
left there for context at the beginning):

 | Once the use of encrypt-then-MAC has been negotiated, processing of
 | TLS/DTLS packets switches from the standard:
 |
 | encrypt( data || MAC || pad )
 |
 | to the new:
 |
 | encrypt( data || pad ) || MAC
 |
   with the MAC covering the encrypted data as well as metadata, as
   described below.  In TLS [2] notation, the definition of
   GenericBlockCipher is changed, for TLS 1.0 without the explicit
   Initialization Vector (IV), to:

      struct {
          block-ciphered struct {
              opaque content[TLSCompressed.length];
              uint8 padding[GenericBlockCipher.padding_length];
              uint8 padding_length;
          } ciphertext;
          opaque MAC[CipherSpec.hash_size];
      } GenericBlockCipher;

   and for TLS 1.1 and greater with an explicit IV to:

      struct {
          struct {
              opaque IV[SecurityParameters.record_iv_length];
              block-ciphered struct {
                  opaque content[TLSCompressed.length];
                  uint8 padding[GenericBlockCipher.padding_length];
                  uint8 padding_length;
              };
          } ciphertext;
          opaque MAC[SecurityParameters.mac_length];
      } GenericBlockCipher;

   All fields have the same definition as in RFC 2246 and RFC 5246
   respectively, except the MAC which is:

 | MAC(MAC_write_key, seq_num +
 |     TLSCipherText.type +
 |     TLSCipherText.version +
       length of GenericBlockCipher.ciphertext +
       GenericBlockCipher.ciphertext);

   where the length is encoded as two bytes in the usual way.
 | (For DTLS, the sequence number is replaced by the combined epoch and
 | sequence number as per DTLS [4].)
   The input to the MAC function differs from the data sent on the wire
   in two few ways: the first is the prepended sequence number (which,
   with TLS is not on the wire, and with DTLS is on the wire in a
   different position); the second is that the length on the wire
   includes the length of the MAC while the lenght in the input of the
   MAC function does not.

 | Note from the GenericBlockCipher annotation that this only applies to
 | standard block ciphers that have distinct encrypt and MAC operations.
   [rest of the section unchanged]
   [note: no need to recall/redefine TLSCiphertext any more]

Please criticize! (An obvious drawback is it looks quite heavy for an erratum,
compared to the other idea that changes only a few lines.)

Manuel.


From nobody Thu Oct 30 09:10:09 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7B61A005A for ; Thu, 30 Oct 2014 09:10:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NriaX9M9GTb2 for ; Thu, 30 Oct 2014 09:09:59 -0700 (PDT)
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E4131A0043 for ; Thu, 30 Oct 2014 09:09:56 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id 10so4601116lbg.36 for ; Thu, 30 Oct 2014 09:09:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:reply-to:from:to:references :in-reply-to:subject:date:organization:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=Ssn94pDhBfOLIWntJuGmEItv5GlIzVqxEeLGF21iSQw=; b=m+XxNYXfRv7+Zpojf3qA3ntSWosqqa5pG+TWNglk0TTMCTAyT+wae8hy0VBndM9pVX Lkbh4mnDbVCC2fafOs1+7XOQ3hShL415AEwTgLK9yGUCBMl5G+9qYsX2VmOW34Wmvdgw DCheqqMVMI5d1+aqi7gsM8a9hCqfFTQ2K3EsUec7x1oOhzG+c1GTiVla1xiJpUeErRaL /X+XDSkMelbI2iRmXaIizAtvD74+lMXHw/mKyaegkCackIVdZONHr3JyBL1CCBbIN8k5 GetWPD6Xgq2Aqh7G4EUHaHDPme/Dtr+W7fzoq3OUrDHs3u7kEvf7zP7HRDKl2fHszwci /Ifw==
X-Gm-Message-State: ALoCoQmtU5u3EZfj9kI5mBVbNvYihFSJwO2tvrzXbDvNIFaNE0TethjCYyTVyTgEQl94tnMDehNW
X-Received: by 10.152.7.175 with SMTP id k15mr19884437laa.58.1414685394476; Thu, 30 Oct 2014 09:09:54 -0700 (PDT)
Received: from THINK2 ([82.119.170.75]) by mx.google.com with ESMTPSA id h9sm3352855lae.44.2014.10.30.09.09.52 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Oct 2014 09:09:53 -0700 (PDT)
Message-ID: <545262d1.c913980a.262d.ffffb8ac@mx.google.com>
X-Google-Original-Message-ID: <004a01cff45b$f0c30e30$d2492a90$@kahlo@ageto.net>
From: "Christian Kahlo" 
To: "'Peter Gutmann'" , 
References: <9A043F3CF02CD34C8E74AC1594475C739B9DC04D@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DC04D@uxcn10-5.UoA.auckland.ac.nz>
Date: Thu, 30 Oct 2014 17:09:51 +0100
Organization: AGETO Innovation GmbH
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac/0QlyClWW7Q6CgQVidvuiE5f8+/wAFO75A
Content-Language: de
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KUuApcPZoVBRTo_0Ch2Uq5i1ZNE
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: c.kahlo@ageto.net
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 16:10:02 -0000

> >But as stated before I'll have a look in the final RFC and compare it
> to the
> >currently deployed implementation.
> 
> See the more recent messages about this though, there are two possible
> interpretations, both equally valid, so don't go changing things just
> yet :-).

Done so. After reading some dozen eMails and bug reports at different
sites (Google, Mozilla) I think I'm now up to date what the whole
discussion is about.

I understood "TLSCipherText.length" in the MAC-function as the length
of the encrypted and padded data because the MAC is calculated exactly
over this - not anything else. This seemed quite logical to me. But I
now realize that fragment.length != length of the final data block on
the wire. It's more a question of wording - and how it is interpreted.

BTW: @all, after seeing all this: it is far, far easier to talk
to Peter or me directly in case of doubts about EtM than to open
tickets on systems all over the world we aren't aware of. ;-)

So, eid.vx4.net will keep its implementation for all those who
want to check and discuss RFC7366.

Best regards,
Christian



From nobody Thu Oct 30 09:17:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6EF1A0099 for ; Thu, 30 Oct 2014 09:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ1Jr5SzV6WR for ; Thu, 30 Oct 2014 09:17:26 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA9E1A0023 for ; Thu, 30 Oct 2014 09:17:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414685844; x=1446221844; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=9Y0cG4a9Uzr/0pJXf/vUxVPp9lGR8GIgx6pGVMSaJn4=; b=RWer/zAW8g3qYFJCran7a2fDvs/N/4wK7m+7TOR4NnnC1c8ODxbMx1eM 3wpRv0VUoF4uKbVw9/wLzjxUNO5x/HWzTrswsgbZ54090uXINcfgSIFI/ Atd3ZM9K8dXmD7CJWMSDxxtAKvfVrLn8v8YZFKO/lAdONTWTQfp41BJam A=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286691359"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 31 Oct 2014 05:17:22 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Fri, 31 Oct 2014 05:17:22 +1300
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/0XPwJ5+DRaXDcT3GS9QhU9NOHtA==
Date: Thu, 30 Oct 2014 16:17:21 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DC255@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VjXOqhDKpiZhkc4LuBMuYZJy1qI
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 16:17:31 -0000

Manuel P=E9gouri=E9-Gonnard  writes:=0A=
=0A=
>Another (related) idea: explicitly change the definition of=0A=
>GenericBlockCipher when EtM is in use=0A=
=0A=
Henrick had suggested something like that as well, but at that point you're=
=0A=
starting to rewrite chunks of the main TLS RFCs, which may be overkill if t=
he=0A=
goal is merely to explain which length value to use.  That is, it's valuabl=
e=0A=
for a future RFC (e.g. TLS 1.3) where you'd explicitly want to make this th=
e=0A=
standard record format, but it may be a bit heavy going for an erratum that=
's=0A=
only supposed to say "use this value for the length".=0A=
=0A=
The ideal explanation would be as short and concise as possible, and one wh=
ere=0A=
no-one has any concerns about different interpretations.  This was why I wa=
s=0A=
leaning towards the "for the avoidance of any doubt ..." style of annotatio=
n,=0A=
it's a brief clarification to the existing text to clear up ambiguity.  My=
=0A=
concern is that adding a complex technical definition, while very precise, =
may=0A=
then require another erratum later on to explain it.=0A=
=0A=
If anyone can come up with a clear one-paragraph note (which, when posted t=
o=0A=
the list, no-one complains about :-), I'd be happy to use that.=0A=
=0A=
Peter.=


From nobody Thu Oct 30 18:03:21 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3711A8A28 for ; Thu, 30 Oct 2014 18:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E71GE7tRG24 for ; Thu, 30 Oct 2014 18:03:17 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691B71A8A48 for ; Thu, 30 Oct 2014 18:03:12 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 4357754B08; Fri, 31 Oct 2014 02:03:10 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 3A42442DC8; Fri, 31 Oct 2014 02:03:10 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2F9631AF6E; Fri, 31 Oct 2014 02:03:10 +0100 (CET)
In-Reply-To: 
To: Yuhong Bao 
Date: Fri, 31 Oct 2014 02:03:10 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UfTiMw5zSTl9GT5QM_MTGpLoBjA
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 01:03:20 -0000

Yuhong Bao wrote:
> I hope that a Internet-Draft prohibiting SSL 3.0 will be next.
> Maybe make an exception for things like browser download sites
> (it is easy to enable TLS 1.0 in IE6 but for these kind of sites
>  it is probably not worth the effort).

No, why?

This may be unknown to you, but SSLv3 is still perfectly safe to use
within its stated design goals.  Even within the Design Goals stated
for TLSv1.2!

Remember the TLSv1.2 product warning label:

  https://tools.ietf.org/html/rfc5246#page-16

   Any protocol designed for use over TLS must be carefully designed to
   deal with all possible attacks against it.  As a practical matter,
   this means that the protocol designer must be aware of what security
   properties TLS does and does not provide and cannot safely rely on
   the latter.

And recap the stated properties of the protocol:

  https://tools.ietf.org/html/rfc5246#appendix-F

  https://tools.ietf.org/html/rfc5246#appendix-F.2


TLS up to and including TLSv1.2 similar to its predecessor SSLv3
*NEVER* *EVER* promised to provide any protection against attacks
such as BEAST, CRIME, Poodle or the RC4-attacks.  All of these
attacks have the prerequiste of almost full control over the behaviour
of an endpoint.  Remove the control-over-the-endpoint from these
attack scenarios, and none of these attacks will be possible anymore.

Btw. when I just did online-banking a few hours ago, I noticed
a longer numeric "token" variable at the end of the URL that changed
with every mouseclick and navigation on the page.  Seems like someone
properly realized that the root of all evil is applications on top
of TLS using disclosing authentication schemes.



Poodle targets the final block of CBC padding, and has an "efficiency"
of recovering 1 byte of plaintext per 256 TLS sessions during which
the server encounters 255 MAC errors on the app data (something that
normally occurs one per week or less).
As such Poodle looks like an extremely "noisy" attack to me.


The plaintext pattern that Poodle is trying to achieve for the final
CBC block of an SSL record looks like this:

       64-bit blockcipher (DES, 3DES, IDEA)
                 XX XX XX XX XX XX XX 07
      128-bit blockcipher (AES, CAMELIA, SEED, CAST):
                 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 0F


Does anyone remeber Serge Vaudenay's original problem as a result from
the incorrect ordering of pad and mac in the SSL GenericBlockCipher
PDU processing, i.e.
the use of the unsafe "mac + pad + encrypt"
rather than a safe "pad + mac + encrypt":

       http://lasec.epfl.ch/php_code/publications/search.php?ref=Vau01
       http://lasec.epfl.ch/php_code/publications/search.php?ref=Vau02a

Didn't the the plaintext pattern that Vaudenay suggested in trying to
achieve for the final CBC block look like this:

       64-bit blockcipher (DES, 3DES, IDEA)
                 XX XX XX XX XX XX XX 00
      128-bit blockcipher (AES, CAMELIA, SEED, CAST):
                 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 00

I can not see much of a difference between original Vaudenay and Poodle,
and the efficieny is exactly the same: plaintext recovery of 1 byte per 256
TLS sessions.


Just that the TLS WG actually *NEVER* followed Vaudenay's advice
by moving to "pad + mac + encrypt", which would have reliably
thwarted Lucky thirteen and Poodle.

If there was ever reason to "Panic", this was back in 2001 when the
problem was first described.  IMHO.


-Martin


From nobody Thu Oct 30 18:26:30 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E69E1A8A45 for ; Thu, 30 Oct 2014 18:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9M4Od9yHZ94 for ; Thu, 30 Oct 2014 18:26:24 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C411A8A3A for ; Thu, 30 Oct 2014 18:26:24 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 4328B6E99B; Fri, 31 Oct 2014 02:26:22 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 35CBF449BE; Fri, 31 Oct 2014 02:26:22 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2D0721AF6E; Fri, 31 Oct 2014 02:26:22 +0100 (CET)
In-Reply-To: 
To: Bodo Moeller 
Date: Fri, 31 Oct 2014 02:26:22 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141031012622.2D0721AF6E@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5n9Xbrvg_NIrM-rCOgSaf08pX3s
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 01:26:27 -0000

Bodo Moeller wrote:
> Martin Rex :
> 
>> Rather than aborthing the TLS handshake, the server ought to include
>> a TLS extension in the ServerHello indicating that he recognized a
>> potentially inappropriate fallback and otherwise continue the TLS handshake
>> in the regular fashion, leaving the decision of whether&how to continue
>> entirely up to those clients who do perform insecure fallbacks.
> 
>
> I just don't think that the additional benefit (per connection)
> is worth the additional computational effort (per connection), and the
> extra latency: for many clients, there is *no* additional benefit at all.

There is a *HUGE* benefit for clients.  They will be able to properly
recognize accidental fallbacks that should not have happened in the
first place.  Otherwise it takes bug reports and several years before
client connection management failures get fixed.


> 
> I'm also concerned about the mechanism being more error-prone if servers
> don't respond with a fatal alert.  If it's a warning alert (or other
> signal) instead

NO Alert at all.  Regular continuation of the handshake.

>
> clients will require additional code to handle this properly,
> whereas reacting to a fatal alert is something that all TLS
> implementations already know how to do.

That reaction is called interop failure.  That is the far opposite
of what IETF working groups are supposed to consciously cause to happen
when the alternative would be to make interop succeed.

As I keep saying, the server decides based on the server's policy
whether it is OK to proceed with the handshake and pick his favorite
properties from the parameters proposed by the Client, and then it is
up to the client to determine, based on the client's own policy,
whether the client is OK to continue.

The TLS protocol offers a negotiation of protocol parameters, and it
actually cryptographically protects this negotiation.  It is silly for
a client to propose parameters that it actually does not want to
have negotiated.  


> 
> We could create a client-side signal that allows the client to specify the
> desired AlertLevel, but this again would add further complexity to the
> protocol (by making server behavior more complex).

The Server ought to continue the regular TLS handshake SUCCESSFULLY.
But it could include a ServerHelloExtension in response that tells
the client "if you really think you could do better, and your app
on top contains the megabyte of flawed "downgrade dance" app coding
that makes Poodle so successful, then you may want to reconsider
your ClientHello offer."

Even when falling back all the way to SSL VERSION 2.0 CLIENT-HELLO,
should be safe and spec-compliant for the client to offer
at least { 0x03, 0x01 } aka TLSv1.0 and the mandatory-to-implement
TLSv1.2 cipher suite TLS_RSA_WITH_AES_128_CBC_SHA

   https://tools.ietf.org/html/rfc5246#section-9

and I really do not understand why all those downgrade dancers
didn't fix their code at least when they renego-patched, because
back then we discussed rather extensively how bad it would be if
an attacker would be able to remove a capability from ClientHello
that both client and server support, and the client even believes
to be a necessity.


-Martin


From nobody Thu Oct 30 18:56:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194E21A8A52 for ; Thu, 30 Oct 2014 18:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdO1ilg9xoyT for ; Thu, 30 Oct 2014 18:56:20 -0700 (PDT)
Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A9F1A8A60 for ; Thu, 30 Oct 2014 18:56:20 -0700 (PDT)
Received: by mail-yh0-f46.google.com with SMTP id a41so2233900yho.5 for ; Thu, 30 Oct 2014 18:56:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KVT9lJPk9IK8b8hgIrhOe3LYuLZ0kR0qK7FVTCf03Dg=; b=A8hzpoCgdl6QXlmZllMaTdD0LG17Txo/iuIdmPlQes9/q6EVf+0BpASL9iSj+UT8In ynA4001ItBFcBIW1O/3Gs6oXyXYqaxYeQWzqhQuhwjbxH6fULFcs6QvHqr3hXFRFEil+ +ow6YstfIo4L2IyLKAHaIuD9ji5bN2oePcJmvo8Ue1zpVWi0POxbJLZzVe+4zZUvRFSb dVIVFXIPdlr5zG4SC4b0WGpa7vegGJbMSExuzuszT6h+KdJVcpSq2NxN6X3hleB66uwz xoUX1Avu0UyMWWM0bALWgQqpX4+wEXfhrL2tO8POFb4f2D4BPyILm5LgSAFVQ9hyllVB tgjA==
MIME-Version: 1.0
X-Received: by 10.236.2.5 with SMTP id 5mr5517545yhe.179.1414720579699; Thu, 30 Oct 2014 18:56:19 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Thu, 30 Oct 2014 18:56:19 -0700 (PDT)
In-Reply-To: <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp>
References:  <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp>
Date: Thu, 30 Oct 2014 18:56:19 -0700
Message-ID: 
From: Watson Ladd 
To: "mrex@sap.com" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dA6mvlhRwrOJysH8tDBrNQ-Q4Ck
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 01:56:23 -0000

On Thu, Oct 30, 2014 at 6:03 PM, Martin Rex  wrote:
> Yuhong Bao wrote:
>> I hope that a Internet-Draft prohibiting SSL 3.0 will be next.
>> Maybe make an exception for things like browser download sites
>> (it is easy to enable TLS 1.0 in IE6 but for these kind of sites
>>  it is probably not worth the effort).
>
> No, why?
>
> This may be unknown to you, but SSLv3 is still perfectly safe to use
> within its stated design goals.  Even within the Design Goals stated
> for TLSv1.2!
>
> Remember the TLSv1.2 product warning label:
>
>   https://tools.ietf.org/html/rfc5246#page-16
>
>    Any protocol designed for use over TLS must be carefully designed to
>    deal with all possible attacks against it.  As a practical matter,
>    this means that the protocol designer must be aware of what security
>    properties TLS does and does not provide and cannot safely rely on
>    the latter.
>
> And recap the stated properties of the protocol:
>
>   https://tools.ietf.org/html/rfc5246#appendix-F
>
>   https://tools.ietf.org/html/rfc5246#appendix-F.2

Those sources say TLS provides a secure channel. Maybe that means
something different to you then me, but to me that means
INT-PTXT+IND-CCA2, aka "looks like a wire strung between the
machines", aka "I can do what I want, and an attacker will have no
hope". Or was this warning intended to be "don't trust this with
anything important, because it can bite"?

Your reading amounts to saying, that because TLS is insecure, the
provided properties are empty, and that's fine. I think most people
would disagree with that assertion, especially given the detailed
enumeration of security properties following that quote.

>
>
> TLS up to and including TLSv1.2 similar to its predecessor SSLv3
> *NEVER* *EVER* promised to provide any protection against attacks
> such as BEAST, CRIME, Poodle or the RC4-attacks.  All of these
> attacks have the prerequiste of almost full control over the behaviour
> of an endpoint.  Remove the control-over-the-endpoint from these
> attack scenarios, and none of these attacks will be possible anymore.

So TLS wasn't designed to satisfy standard security properties?
Browsers were never intended to run Javascript?

This seems like an argument for replacing TLS with something secure.

>
> Btw. when I just did online-banking a few hours ago, I noticed
> a longer numeric "token" variable at the end of the URL that changed
> with every mouseclick and navigation on the page.  Seems like someone
> properly realized that the root of all evil is applications on top
> of TLS using disclosing authentication schemes.

No, the root of all evil is hiring a biology student for a summer to
make a security protocol. It's a miracle SSLv3 works at all, showing
that the Lord protects drunks, fools, and interns.

(Also, that's for CSRF protection. The authentication is probably by a
cookie, and if that cookie is stolen, the CSRF protection doesn't stop
an attacker from going to the login form, which checks that the user
is logged in and kaboom. Changing authorization cookies shouldn't be
necessary: the only reason you are proposing it is that SSL v3 fails
to provide necessary security properties.)

>
>
>
> Poodle targets the final block of CBC padding, and has an "efficiency"
> of recovering 1 byte of plaintext per 256 TLS sessions during which
> the server encounters 255 MAC errors on the app data (something that
> normally occurs one per week or less).
> As such Poodle looks like an extremely "noisy" attack to me.

Okay, so the server logs the MAC errors, and then what happens? And
why should I have to watch the logs to ensure that I'm not being
attacked when I turned on SSL? It's secure ainit?

>
>
> The plaintext pattern that Poodle is trying to achieve for the final
> CBC block of an SSL record looks like this:
>
>        64-bit blockcipher (DES, 3DES, IDEA)
>                  XX XX XX XX XX XX XX 07
>       128-bit blockcipher (AES, CAMELIA, SEED, CAST):
>                  XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 0F
>
>
> Does anyone remeber Serge Vaudenay's original problem as a result from
> the incorrect ordering of pad and mac in the SSL GenericBlockCipher
> PDU processing, i.e.
> the use of the unsafe "mac + pad + encrypt"
> rather than a safe "pad + mac + encrypt":
>
>        http://lasec.epfl.ch/php_code/publications/search.php?ref=Vau01
>        http://lasec.epfl.ch/php_code/publications/search.php?ref=Vau02a
>
> Didn't the the plaintext pattern that Vaudenay suggested in trying to
> achieve for the final CBC block look like this:
>
>        64-bit blockcipher (DES, 3DES, IDEA)
>                  XX XX XX XX XX XX XX 00
>       128-bit blockcipher (AES, CAMELIA, SEED, CAST):
>                  XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 00
>
> I can not see much of a difference between original Vaudenay and Poodle,
> and the efficieny is exactly the same: plaintext recovery of 1 byte per 256
> TLS sessions.

Yes, Bodo Moeller and I already noted this in several emails to
various mailing lists, Kenny Paterson said this on Twitter, etc.

>
>
> Just that the TLS WG actually *NEVER* followed Vaudenay's advice
> by moving to "pad + mac + encrypt", which would have reliably
> thwarted Lucky thirteen and Poodle.

They also didn't follow the advice of everyone else to encrypt then
mac, which would have fixed it. Furthermore, we did finally publish an
encrypt then MAC draft, which also fixes the problem, about 13 years
later.

>
> If there was ever reason to "Panic", this was back in 2001 when the
> problem was first described.  IMHO.

So why don't we fix it now? And why didn't you discover it yourself,
or propose a fix then? Every single time we've tried to solve
problems, you've insisted that they are really the user's problem. And
when these problems are rediscovered, you now argue we should have
fixed them the first time, and that we didn't shows how unimportant
they are, even when they steal someones money live on stage as a
demonstration.

In fact, you've even gone so far as to claim issues you thought were
security flaws when you discovered them, weren't. What's the goal
here? To get the WG to give up and never change the protocol ever
again?

Sincerely,
Watson Ladd

>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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


From nobody Thu Oct 30 19:31:47 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742FE1A8A86 for ; Thu, 30 Oct 2014 19:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWmSda4z5YHD for ; Thu, 30 Oct 2014 19:31:42 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF281A8A83 for ; Thu, 30 Oct 2014 19:31:41 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id E721054B08; Fri, 31 Oct 2014 03:31:39 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id DA76F44A06; Fri, 31 Oct 2014 03:31:39 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id CBB741AF6E; Fri, 31 Oct 2014 03:31:39 +0100 (CET)
In-Reply-To: 
To: Watson Ladd 
Date: Fri, 31 Oct 2014 03:31:39 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141031023139.CBB741AF6E@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pBOLTnn-2-OzfFiy_fUBQW9Sk-k
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 02:31:44 -0000

Watson Ladd wrote:
>>
>> And recap the stated properties of the protocol:
>>
>>   https://tools.ietf.org/html/rfc5246#appendix-F
>>
>>   https://tools.ietf.org/html/rfc5246#appendix-F.2
> 
> Those sources say TLS provides a secure channel.  Maybe that means
> something different to you then me, but to me that means
> INT-PTXT+IND-CCA2, aka "looks like a wire strung between the
> machines", aka "I can do what I want, and an attacker will have no
> hope". Or was this warning intended to be "don't trust this with
> anything important, because it can bite"?

To me, the second sentence of Appendix F:

   This document makes several traditional assumptions, including that
   attackers have substantial computational resources and cannot obtain
   secret information from sources outside the protocol.

says pretty clearly that TLS is not designed to provide protection from
an attacker who can gain almost full control over one of the communication
endpoints and can exploit this to get data of his own liking and data
that the attacker would like to discover mixed according to the attackers
choice with attacker supplied data and sent over the very same TLS-protected
communication channel.


An attack which I would consider scary is one that works like an
attack against the OpenSSL CVE-2014-0224 out-of-sequence ChangeCipherSpec
implementation bug (which is not a protocol defect, mind you).

When one of the 80 million affected andoid clients (smartphones, tablets)
talks to a still-vulnerable server, then a pure network-MitM attacker
(with ZERO control over the endpoint) can get in between the two,
read and modify the entire communication in both directions to his
own liking, and neither communication will notice anything unusual
or be aware that this attack ever happened.  no errors, no unusual
delays, no additional load, no failed requests, no repeated requests
no downgrades.



-Martin


From nobody Thu Oct 30 20:12:18 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4CE1A8A9A for ; Thu, 30 Oct 2014 20:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level: 
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK2Uid93dPtx for ; Thu, 30 Oct 2014 20:12:11 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB3C1A8A83 for ; Thu, 30 Oct 2014 20:12:10 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id E43DD33D067; Fri, 31 Oct 2014 03:12:09 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: mrex@sap.com
References:  <20141031023139.CBB741AF6E@ld9781.wdf.sap.corp>
From: Geoffrey Keating 
Date: 30 Oct 2014 20:12:09 -0700
In-Reply-To: <20141031023139.CBB741AF6E@ld9781.wdf.sap.corp>
Message-ID: 
Lines: 24
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2BWkS7LRpDJZj21NT-qo6sPN9Yk
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 03:12:14 -0000

mrex@sap.com (Martin Rex) writes:

> To me, the second sentence of Appendix F:
> 
>    This document makes several traditional assumptions, including that
>    attackers have substantial computational resources and cannot obtain
>    secret information from sources outside the protocol.
> 
> says pretty clearly that TLS is not designed to provide protection from
> an attacker who can gain almost full control over one of the communication
> endpoints and can exploit this to get data of his own liking and data
> that the attacker would like to discover mixed according to the attackers
> choice with attacker supplied data and sent over the very same TLS-protected
> communication channel.

Surely one traditional assumption is that an attacker can create
messages of his own and get them inserted into the stream?  Including
the possibility of intentionally causing a lot of traffic?

I'm fairly sure that one of the tactics used in WW2 to get 'cribs' to
break ENIGMA was to intentionally do things that would cause the enemy
to send a message with known contents, like sending an apparently
valuable target within vision of a U-boat that could not attack it, in
the hope the U-boat would report.


From nobody Thu Oct 30 20:39:53 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7499B1A8A94 for ; Thu, 30 Oct 2014 20:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVA1823BcE23 for ; Thu, 30 Oct 2014 20:39:49 -0700 (PDT)
Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D8C1A8A08 for ; Thu, 30 Oct 2014 20:39:49 -0700 (PDT)
Received: by mail-yh0-f42.google.com with SMTP id 29so2500699yhl.1 for ; Thu, 30 Oct 2014 20:39:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3ADWxevduGrYPUvfL5kPNPx2WiZHkK9cU8A9xz8XNPo=; b=0m7nBkqmjLE955uFFGe16ExmiAvyZAVX16FrsPAiQOEzBn17wsVDmIouMCBnz1SRKW Cu3vgvTqxTN8xJU3HSTlNrFYfACiUSg6eQNbME5R4EvTIMdbGHj8ttXmaVIS+9mPNTl3 nifUT2ToPHSjfanZlQT5HYl405HRDkfQF5s0l7fUQn4IWpTK2JJS2Y12gp9ojQL82fAH HUN2sg2BWIoyd5LAw3AjJrTvirWYHNyBLYQbS1OlRQLoMZBetJagMPKQ2S4qCVYLsitu Fc075Bm0oB35vHch1QSsYoOyckQDN2Q54m5+Ypy0EGjar6JKhTLf1rAuzxN4c6sidIRj 2RfA==
MIME-Version: 1.0
X-Received: by 10.170.214.6 with SMTP id g6mr2233475ykf.34.1414726788578; Thu, 30 Oct 2014 20:39:48 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Thu, 30 Oct 2014 20:39:48 -0700 (PDT)
In-Reply-To: <20141031023139.CBB741AF6E@ld9781.wdf.sap.corp>
References:  <20141031023139.CBB741AF6E@ld9781.wdf.sap.corp>
Date: Thu, 30 Oct 2014 20:39:48 -0700
Message-ID: 
From: Watson Ladd 
To: "mrex@sap.com" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tQ-lgt7EMob99QEyhE42MeJCnV4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 03:39:51 -0000

On Thu, Oct 30, 2014 at 7:31 PM, Martin Rex  wrote:
> Watson Ladd wrote:
>>>
>>> And recap the stated properties of the protocol:
>>>
>>>   https://tools.ietf.org/html/rfc5246#appendix-F
>>>
>>>   https://tools.ietf.org/html/rfc5246#appendix-F.2
>>
>> Those sources say TLS provides a secure channel.  Maybe that means
>> something different to you then me, but to me that means
>> INT-PTXT+IND-CCA2, aka "looks like a wire strung between the
>> machines", aka "I can do what I want, and an attacker will have no
>> hope". Or was this warning intended to be "don't trust this with
>> anything important, because it can bite"?
>
> To me, the second sentence of Appendix F:
>
>    This document makes several traditional assumptions, including that
>    attackers have substantial computational resources and cannot obtain
>    secret information from sources outside the protocol.
>
> says pretty clearly that TLS is not designed to provide protection from
> an attacker who can gain almost full control over one of the communication
> endpoints and can exploit this to get data of his own liking and data
> that the attacker would like to discover mixed according to the attackers
> choice with attacker supplied data and sent over the very same TLS-protected
> communication channel.

So SSL v3 was not intended for use with browsers, despite being
developed by Netscape for use in browsers? And later versions were
also not for use in browsers? And despite the fact that TLS 1.1 fixed
bugs in TLS 1.0 that were only exploitable through doing the very
thing you insist TLS wasn't designed to handle, TLS 1.1 wasn't
designed to work in browsers either? Isn't this an argument that
browsers should not use SSL v3, and servers shouldn't either?

Is this argument leading to "let's make a protocol that works for
browsers"? Or is it leading to "let's not use browsers"?


> An attack which I would consider scary is one that works like an
> attack against the OpenSSL CVE-2014-0224 out-of-sequence ChangeCipherSpec
> implementation bug (which is not a protocol defect, mind you).
>
> When one of the 80 million affected andoid clients (smartphones, tablets)
> talks to a still-vulnerable server, then a pure network-MitM attacker
> (with ZERO control over the endpoint) can get in between the two,
> read and modify the entire communication in both directions to his
> own liking, and neither communication will notice anything unusual
> or be aware that this attack ever happened.  no errors, no unusual
> delays, no additional load, no failed requests, no repeated requests
> no downgrades.

What makes you think that noisy attacks get noticed and stopped?

>
>
>
> -Martin



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


From SRS0=EU1W=7W=acm.org=bmoeller@srs.kundenserver.de  Fri Oct 31 06:15:39 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3291A0029 for ; Fri, 31 Oct 2014 06:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.762
X-Spam-Level: *
X-Spam-Status: No, score=1.762 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvV-HjWdTeuW for ; Fri, 31 Oct 2014 06:15:38 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16F21A001B for ; Fri, 31 Oct 2014 06:15:37 -0700 (PDT)
Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0MQNoq-1XenAx15tE-00TjfR; Fri, 31 Oct 2014 14:15:35 +0100
Received: by mail-yh0-f54.google.com with SMTP id 29so2852974yhl.41 for ; Fri, 31 Oct 2014 06:15:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.220.97 with SMTP id n91mr13664338yhp.127.1414761333992;  Fri, 31 Oct 2014 06:15:33 -0700 (PDT)
Received: by 10.170.99.4 with HTTP; Fri, 31 Oct 2014 06:15:33 -0700 (PDT)
In-Reply-To: 
References:  <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp> 
Date: Fri, 31 Oct 2014 14:15:33 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c23220c134ea0506b7ca05
X-Provags-ID: V02:K0:m083EAHGWG7opn68KnbpufmErIuN5E3sotEH77bQkOR UvM0MrWl+t34HI0wX2tBIOwczTo/ylkpWxIHaeIJ9xsCOKzdq2 8yP4qg9T8i25dSVY1J2dS6pVBFb0687venslLdXCgTNhZWQ9nr 4gdjJNTNioTTTsKpwY9N6JaJOoqgPRpQ/s8Z6KtgZ6Wt3No1Ma 7qtuq7uN0G9SSyZONyHGbRffISRAzEzDSMYqhyaATwO1L5rtKl tDEnJAq6A5UZfND+TiXGPfvWj1WRD1yOsBvVYBJx+J+jiMGe+d wf80oThChTfPJ9Rwb7+c+XWp3HCwT2/y3p9TNc7/bhnl13n0/3 6WZdcoXxEhk80KDYFz+mtwNA2GSbSI2BpXXyyKywgMK/n/0xGM j0tkyFMSBRDHQA3qRyepquJOmPZmuNi7qShWi8QPTDtMThgpid Mxr4W
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k3BvZ1NTVohZDXj-jkoSRzgdC0w
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 13:18:30 -0000

--001a11c23220c134ea0506b7ca05
Content-Type: text/plain; charset=UTF-8

Watson Ladd :

No, the root of all evil is hiring a biology student for a summer to
> make a security protocol. It's a miracle SSLv3 works at all, showing
> that the Lord protects drunks, fools, and interns.


I don't think that's fair to Paul Kocher; see also
https://www.usenix.org/legacy/publications/library/proceedings/ec96/full_papers/wagner/wagner.pdf
for a protocol analysis done by people that I think don't have a biology
background. (Was Paul an intern or a paid consultant at that time? I
thought the latter [cf.
http://www.informatik.uni-trier.de/~ley/pers/hd/k/Kocher:Paul_C=]. He'd
been a consultant to RSA Data Security before, although the only thing I
seem to remember about his work at that time was that he found not much
wrong with RC4.)

It seems pretty safe to say that Phil Rogaway would have been able to spot
additional problems and improve the SSL 3.0 protocol, but this was years
before there was a systematic understanding of many of the relevant
concepts. Chosen-ciphertext attacks were a thing, but "authenticated
encryption" was unheard of. This was even before
http://web.cs.ucdavis.edu/~rogaway/papers/sym-enc.pdf.

Bodo

--001a11c23220c134ea0506b7ca05
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Wats=
on Ladd <watsonbladd@gmail.com>:

No, the root=
 of all evil is hiring a biology student for a summer to

make a security protocol. It's a miracle SSLv3 works at all, showing
that the Lord protects drunks, fools, and interns.

I don't think that's fair to Paul Kocher; see also https://www.usenix.org/legacy/publications/libr=
ary/proceedings/ec96/full_papers/wagner/wagner.pdf for a protocol analy=
sis done by people that I think don't have a biology background. (Was P=
aul an intern or a paid consultant at that time? I thought the latter [cf. =
http://www.informatik.uni-trier.de/~ley/pers/hd/k/Kocher:Paul_C=3D=
]. He'd been a consultant to RSA Data Security before, although the onl=
y thing I seem to remember about his work at that time was that he found no=
t much wrong with RC4.)

It seems pretty safe to sa=
y that Phil Rogaway would have been able to spot additional problems and im=
prove the SSL 3.0 protocol, but this was years before there was a systemati=
c understanding of many of the relevant concepts. Chosen-ciphertext attacks=
 were a thing, but "authenticated encryption" was unheard of. Thi=
s was even before http://web.cs.ucdavis.edu/~rogaway/papers/sym-enc.pdf.

Bodo



--001a11c23220c134ea0506b7ca05--


From nobody Fri Oct 31 07:15:12 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDC81A007D for ; Fri, 31 Oct 2014 07:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVqLXdn7tFgw for ; Fri, 31 Oct 2014 07:15:05 -0700 (PDT)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2911A0013 for ; Fri, 31 Oct 2014 07:15:05 -0700 (PDT)
Received: by mail-yk0-f176.google.com with SMTP id 10so3320273ykt.35 for ; Fri, 31 Oct 2014 07:15:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Zb97qfO2O7HRRJGxl6XAHaH0BfuReaG7u5yqRAlGuZU=; b=l0yMRLAUkKsg9Fa8uuSkfi0HP2qhEJ979wRJF+Bzdm07LeKIsinBwXsT+TzDCKTFJp z5bclEzc3ErCHAyPDMz4wuev/SZ4CWHIFsvY/nPWA5a9qwqfsLW885ru8L3ypGP5IF9r JmfV+kPdezP8c4R1Gv7cNOJEIB0DXzqdDs5xyM/scbhf001yN+CpbFOOSkwa+lBie9wH Z+4UvQOqxyw6G+YaMyo4d0M+NUADaQmvhQPM8mlhztjVdEskfZKQmoy9oIsdnjCW5qWn RGG6zXkg3MOkgEuE0UWCokJT0TSrPmeor1TGhbdOl+7HExA4E/x8zp6HuId5XfdNtgUY 1Omg==
MIME-Version: 1.0
X-Received: by 10.170.214.6 with SMTP id g6mr5328630ykf.34.1414764904851; Fri, 31 Oct 2014 07:15:04 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Fri, 31 Oct 2014 07:15:04 -0700 (PDT)
In-Reply-To: 
References:  <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp>  
Date: Fri, 31 Oct 2014 07:15:04 -0700
Message-ID: 
From: Watson Ladd 
To: Bodo Moeller 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VZho_pDdXNHxTvkyME19Qba2ZEw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 14:15:08 -0000

On Oct 31, 2014 6:18 AM, "Bodo Moeller"  wrote:
>
> Watson Ladd :
>
>> No, the root of all evil is hiring a biology student for a summer to
>> make a security protocol. It's a miracle SSLv3 works at all, showing
>> that the Lord protects drunks, fools, and interns.
>
>
> I don't think that's fair to Paul Kocher; see also https://www.usenix.org=
/legacy/publications/library/proceedings/ec96/full_papers/wagner/wagner.pdf=
 for a protocol analysis done by people that I think don't have a biology b=
ackground. (Was Paul an intern or a paid consultant at that time? I thought=
 the latter [cf. http://www.informatik.uni-trier.de/~ley/pers/hd/k/Kocher:P=
aul_C=3D]. He'd been a consultant to RSA Data Security before, although the=
 only thing I seem to remember about his work at that time was that he foun=
d not much wrong with RC4.)

Paul Kocher did invent side channel analysis a few years later.
Contrast TLS response to protocol flaws to that of IPsec: The first
round of IPsec was terrible. So a second version was developed, which
was much better and is widely used today. By contrast, the improved
version of SSL v3 wasn't, and each successive version never fully
addressed the security issues.

>
> It seems pretty safe to say that Phil Rogaway would have been able to spo=
t additional problems and improve the SSL 3.0 protocol, but this was years =
before there was a systematic understanding of many of the relevant concept=
s. Chosen-ciphertext attacks were a thing, but "authenticated encryption" w=
as unheard of. This was even before http://web.cs.ucdavis.edu/~rogaway/pape=
rs/sym-enc.pdf

You're understating the degree of knowledge at the time, and
overstating the extent to which open questions needed to be answered
to see that SSL v3 was flawed. Again, read what Rogaway said about
IPsec, and ask "did this apply to SSL?"

No one would have caught the decryption oracle in PKCS 1.5 or
renegotiation, or Triple Handshake at the time. But all the attacks
we're discussing rely on record layer choices that were known at the
time they were made to have secure alternatives. Was the Rogaway IPsec
comment document not written in the 1994-1995 period?

The question is not why SSL v3 got it wrong. The question is why we
didn't get it right a few years later, and stop using broken
protocols. You wrote in 2004 that one byte could be extracted from a
SSL v3 ciphertext, thus breaking confidentiality completely. Yet it's
not until 2014 that this actually leads to action on depreciating SSL
v3.

Sincerely,
Watson Ladd

>
> Bodo
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From nobody Fri Oct 31 07:20:01 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93ED41A0060 for ; Fri, 31 Oct 2014 07:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSC6Cq9_eBb8 for ; Fri, 31 Oct 2014 07:19:57 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B02231A000E for ; Fri, 31 Oct 2014 07:19:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 03D69BE0D for ; Fri, 31 Oct 2014 14:19:57 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWGfw3s2wc3g for ; Fri, 31 Oct 2014 14:19:56 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D64EEBDF8 for ; Fri, 31 Oct 2014 14:19:56 +0000 (GMT)
Message-ID: <54539A8C.3000501@cs.tcd.ie>
Date: Fri, 31 Oct 2014 14:19:56 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "tls@ietf.org" 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/acPMVFE8wpLKe7Bmh_I7Q1vfckk
Subject: [TLS] Conflict review for draft-dthakore-tls-authz
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 14:19:59 -0000

Hi,

The authors of draft-dthakore-tls-authz [1] presented their work
to the TLS WG some time ago and IIRC there wasn't interest
in pursuing that. So as is fairly common in such cases, they have
asked the independent submissions editor (ISE) to publish their
work as an RFC in the independent stream.

As part of that, the IESG do a conflict review [2] to determine
if the work conflicts with ongoing IETF work, as described in
RFC 5742 [3]. (See section 3 of that for the possible responses
the IESG can give.)

So, please let me know (say by Nov 17) if you think that this
work does conflict with the TLS WG's efforts. (Silence is fine
if you think it does not conflict.)

If you have technical comments on the draft itself, then I'm
sure the authors and the ISE would be interested in those.

If you have process questions about this, feel free to ask me
or the WG chairs.

Thanks,
S.

[1] https://datatracker.ietf.org/doc/draft-dthakore-tls-authz/
[2] https://datatracker.ietf.org/doc/conflict-review-dthakore-tls-authz/
[3] https://tools.ietf.org/html/rfc5742


From nobody Fri Oct 31 07:25:01 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B980F1A9025 for ; Fri, 31 Oct 2014 07:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.462
X-Spam-Level: 
X-Spam-Status: No, score=0.462 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0kZcVfDqXur for ; Fri, 31 Oct 2014 07:24:56 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9D01A88BC for ; Fri, 31 Oct 2014 07:24:56 -0700 (PDT)
Received: from mail-yh0-f45.google.com (mail-yh0-f45.google.com [209.85.213.45]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0MCuUJ-1XsDTS2mMV-009iGq; Fri, 31 Oct 2014 15:24:54 +0100
Received: by mail-yh0-f45.google.com with SMTP id f73so2700836yha.4 for ; Fri, 31 Oct 2014 07:24:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.220.97 with SMTP id n91mr14142229yhp.127.1414765492529;  Fri, 31 Oct 2014 07:24:52 -0700 (PDT)
Received: by 10.170.99.4 with HTTP; Fri, 31 Oct 2014 07:24:52 -0700 (PDT)
In-Reply-To: 
References:  <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp>   
Date: Fri, 31 Oct 2014 15:24:52 +0100
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c232209f71670506b8c20b
X-Provags-ID: V02:K0:fLh8szG4IZC5HNCX0hSos7q6roYBPA4Sp9mEnekw+xe 2RkGWbkOG3pZs1jKmIkTbM8fNIYSUQeWPiR3neHQmlB4qZGYFV XI04iq+KzwpsFIx1erKRD1qVW4ix0BG0iCqV+j47ZjzGkaFE4i YxVjyiYM3e2ZilxKV8QaKgwajobQwgKZRyCVoT7yLxQpFQOGRM WIL1fK1YrireHh4a6+H5uDqOzWnr5qC9pLDQ67vUCNipLDfJA+ 2koRCl/OgR9jDzn0TApLkF9l1bC6LY3gCG8hbY6K93R2/3B0qW r7FZfjsCEelpqiOeFuUjF1p+jOSO9n+VvUtrq+DkjNapRiIxz3 QtLgabeWgSHrjCeYj4ZIC7qf58e9ACyEu3jF1mO48jyehcqp7v 8L3IDesOaGUGMaokbWAXOVkVS44bo/bBU4QVRgEfKScvdzelOb Pm9LK
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bkTC9zEeTJNfEfqmnRCezeIlObY
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 14:24:57 -0000

--001a11c232209f71670506b8c20b
Content-Type: text/plain; charset=UTF-8

Watson Ladd :

You're understating the degree of knowledge at the time,


I don't think so. My intent was to highlight the difference between "known
at the time" and "widely known among experts at the time". As I pointed
out, you didn't have to be a biology major at the time to miss the
("known") problems.

The question is not why SSL v3 got it wrong. The question is why we
> didn't get it right a few years later


These both are (different) questions. I had commented on your comments on
the former.

Bodo

--001a11c232209f71670506b8c20b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Wats=
on Ladd <watsonbladd@gmail.com>:

You=
're understating the degree of knowledge at the time,

I don't think so. My intent was to highlight the =
difference between "known at the time" and "widely known amo=
ng experts at the time". As I pointed out, you didn't have to be a=
 biology major at the time to miss the ("known") problems.
<=
div>
=


The question is not why SSL v3 got it wrong. The question is why we

didn't get it right a few years later

T=
hese both are (different) questions. I had commented on your comments on th=
e former.

Bodo



--001a11c232209f71670506b8c20b--


From nobody Fri Oct 31 07:39:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B5F1A9039 for ; Fri, 31 Oct 2014 07:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G77WP7St_cCZ for ; Fri, 31 Oct 2014 07:39:12 -0700 (PDT)
Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC60F1A8AA9 for ; Fri, 31 Oct 2014 07:39:11 -0700 (PDT)
Received: by mail-yh0-f47.google.com with SMTP id i57so2745040yha.20 for ; Fri, 31 Oct 2014 07:39:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LYPQKPofLkRhhacaSU7t6YnEZ3IOwbulAn7LNuco8qY=; b=hFYtPnR+osfGiT3YzdLq0J+2hymXSKxpNxZnZRO/TlMs/bIv+phhBnHjnpen/J3Rnx zbmogbZYGtZY5bwxDCXOL0PNur9itLSvceq51vdZvNQxO0FppnFjOVvgmxgbl+bSyewH wGzxesiD56zepLmN/J5KbRQd0cjmqBh2zyP1hiHHX17H4cq4Sj1MwvL7GQ3ZILXS2N62 HFGh5GqKnRA3rM9sZYUeXMn+N7Xf2azpZNZ5vNsAVLXN0PxA5Z1kwkTQhfQ1tpKRnhzt 5WsgL1b+Y6hO8NA6yU/H9mglFLhJiPSB/nES/eQB3ikWYFltlPhuKj7ZLSWCP6p5sdYo tWWA==
MIME-Version: 1.0
X-Received: by 10.236.30.197 with SMTP id k45mr9495161yha.163.1414766351245; Fri, 31 Oct 2014 07:39:11 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Fri, 31 Oct 2014 07:39:11 -0700 (PDT)
In-Reply-To: 
References:  <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp>    
Date: Fri, 31 Oct 2014 07:39:11 -0700
Message-ID: 
From: Watson Ladd 
To: Bodo Moeller 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QRnoYX7k0m9edkkFEIWBnz1ukNw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 14:39:14 -0000

On Fri, Oct 31, 2014 at 7:24 AM, Bodo Moeller  wrote:
> Watson Ladd :
>
>> You're understating the degree of knowledge at the time,
>
>
> I don't think so. My intent was to highlight the difference between "known
> at the time" and "widely known among experts at the time". As I pointed out,
> you didn't have to be a biology major at the time to miss the ("known")
> problems.

Are you suggesting that Rogaway was the only person who knew that
Encrypt then MAC was correct? I'd have to do a fairly extensive
archive crawl, but I highly doubt this: mathematicians are good at
communicating. In fact, I think most if not all of the researchers in
the field would have known this. But it's very hard to go back and
check.

>
>> The question is not why SSL v3 got it wrong. The question is why we
>> didn't get it right a few years later
>
>
> These both are (different) questions. I had commented on your comments on
> the former.
>
> Bodo
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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


From nobody Fri Oct 31 10:12:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE70B1A00D6 for ; Fri, 31 Oct 2014 10:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.342
X-Spam-Level: 
X-Spam-Status: No, score=0.342 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ihd-7PyxcWsv for ; Fri, 31 Oct 2014 10:12:21 -0700 (PDT)
Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.93.35.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D661A00BA for ; Fri, 31 Oct 2014 10:12:21 -0700 (PDT)
Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 905F0D905FEBF; Fri, 31 Oct 2014 12:12:20 -0500 (CDT)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 7D898D905FE7B for ; Fri, 31 Oct 2014 12:12:20 -0500 (CDT)
Received: from [173.73.121.234] (port=60918 helo=192.168.1.7) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XkFkJ-0003f4-QB; Fri, 31 Oct 2014 12:12:19 -0500
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Sean Turner 
In-Reply-To: 
Date: Fri, 31 Oct 2014 13:12:16 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <74C3734E-DDF8-47DA-AF4A-AFF440C753F4@ieca.com>
References:  <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp> 
To: Watson Ladd 
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 173.73.121.234
X-Exim-ID: 1XkFkJ-0003f4-QB
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (192.168.1.7) [173.73.121.234]:60918
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 2
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1xTWfL8x5WpQNYIp4k-dmIX2ink
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 17:12:22 -0000

On Oct 30, 2014, at 21:56, Watson Ladd  wrote:

> No, the root of all evil is hiring a biology student for a summer to
> make a security protocol. It's a miracle SSLv3 works at all, showing
> that the Lord protects drunks, fools, and interns.

Watson,

Please cease with the personal attacks.  As this is not the first time =
[0] you=92ve been publicly ask you to stop, I have consulted with the AD =
and next time you engage in a personal attack you will be banned from =
the list for a period not to exceed 30 days [1].

J&S (as WG chairs)

[0] http://www.ietf.org/mail-archive/web/tls/current/msg12146.html
[1] http://datatracker.ietf.org/doc/rfc3934/=


From nobody Fri Oct 31 10:17:33 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89DB1A001C for ; Fri, 31 Oct 2014 10:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H96Ta_fCAHps for ; Fri, 31 Oct 2014 10:17:30 -0700 (PDT)
Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981461A0070 for ; Fri, 31 Oct 2014 10:17:30 -0700 (PDT)
Received: by mail-qc0-f177.google.com with SMTP id l6so6133494qcy.8 for ; Fri, 31 Oct 2014 10:17:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TShgXWFprNB6Oug863WfLD9nyAAzYmNKAMLR4XiCMEw=; b=YoOkmppXZrXZUgAjpiulbcB9hxGd1NC/13wJOEPhZGFJMcXpAfzwBrIn6cQSeP/B+4 zyjN20gUvxe8TjNzuxJYXgY99vdFTBk041M5nu/o7iiG5ZBg3XN8fLu+ymmKTvGyidPV PiTK1/TDfzkTTvJeGdStWZqHUjnRVI/e99GEuL8DYVmhHBec4SRKJiWe9M6X1oSUiy3p CLv+YiYdudQ/ctmwJtMjteUWqSG3IBtSFazu/ON/a6dutq860UYfCmjkvWEqP2ZJmK9e L/UuWgbHyAmXOs8mmmgNKBeXMnTVw5hQGnlI9ca8d3eXr06O5Qhc2nU/MXmb8axuk1W2 /ctg==
X-Gm-Message-State: ALoCoQm4vQSGkFJ0XZzk5V/2aQxoxR9Vj3k5vgaBlYOSgquIkAyfEWsQrdApHAS/fZlfvYwlHLJY
MIME-Version: 1.0
X-Received: by 10.224.171.194 with SMTP id i2mr39131307qaz.59.1414775849786; Fri, 31 Oct 2014 10:17:29 -0700 (PDT)
Received: by 10.96.155.202 with HTTP; Fri, 31 Oct 2014 10:17:29 -0700 (PDT)
X-Originating-IP: [67.168.161.122]
In-Reply-To: <74C3734E-DDF8-47DA-AF4A-AFF440C753F4@ieca.com>
References:  <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp>  <74C3734E-DDF8-47DA-AF4A-AFF440C753F4@ieca.com>
Date: Fri, 31 Oct 2014 10:17:29 -0700
Message-ID: 
From: Joseph Salowey 
To: Sean Turner 
Content-Type: multipart/alternative; boundary=001a11c2b276f6b95b0506bb2b7e
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kKqvQLxEvr1zef17a4YONb5NcRw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 17:17:32 -0000

--001a11c2b276f6b95b0506bb2b7e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

SSL 3.0 is historic, but if but if someone wants to write a draft
prohibiting SSL 3.0 the working group can consider adopting it.  We are
closing down this thread since it has diverged off topic.

J&S (as WG chairs)

On Fri, Oct 31, 2014 at 10:12 AM, Sean Turner  wrote:

> On Oct 30, 2014, at 21:56, Watson Ladd  wrote:
>
> > No, the root of all evil is hiring a biology student for a summer to
> > make a security protocol. It's a miracle SSLv3 works at all, showing
> > that the Lord protects drunks, fools, and interns.
>
> Watson,
>
> Please cease with the personal attacks.  As this is not the first time [0=
]
> you=E2=80=99ve been publicly ask you to stop, I have consulted with the A=
D and next
> time you engage in a personal attack you will be banned from the list for=
 a
> period not to exceed 30 days [1].
>
> J&S (as WG chairs)
>
> [0] http://www.ietf.org/mail-archive/web/tls/current/msg12146.html
> [1] http://datatracker.ietf.org/doc/rfc3934/
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a11c2b276f6b95b0506bb2b7e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


SSL 3.0 is historic, but if=C2=A0but if someone wants to write a draft prohibiti=
ng SSL 3.0 the working group can consider adopting it.=C2=A0 We are closing down this thread since it has=
 diverged off topic.

J&S=C2=A0(as WG chairs)
=

On Fri, Oct 31, 2014 at 10:12 AM, Sean Turne=
r <TurnerS@ieca.com> wrote:
On Oct 30, 2014, at 21:56, Watson Ladd <watsonbladd@gmail.com> wrote:



> No, the root of all evil is hiring a biology student for a summer to
> make a security protocol. It's a miracle SSLv3 works at all, showi=
ng

> that the Lord protects drunks, fools, and interns.



Watson,



Please cease with the personal attacks.=C2=A0 As this is not the first time=
 [0] you=E2=80=99ve been publicly ask you to stop, I have consulted with th=
e AD and next time you engage in a personal attack you will be banned from =
the list for a period not to exceed 30 days [1].



J&S (as WG chairs)



[0] http://www.ietf.org/mail-archive/web/tls/current/msg1=
2146.html

[1] =
http://datatracker.ietf.org/doc/rfc3934/


___________________________________=
____________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--001a11c2b276f6b95b0506bb2b7e--


From nobody Fri Oct 31 10:35:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B931A0071 for ; Fri, 31 Oct 2014 10:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.077
X-Spam-Level: 
X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkNj0yApR5Kl for ; Fri, 31 Oct 2014 10:35:35 -0700 (PDT)
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D603E1A0070 for ; Fri, 31 Oct 2014 10:35:34 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id y10so4062592wgg.30 for ; Fri, 31 Oct 2014 10:35:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=k70Iummt8IY4VhKwTYwotTGP77pyEQgcrLs/YgPBX4A=; b=aogP8333vtAlIWi4D4kAMQaSTocj3QABkOsnCbg96/p8ZGVRID5d4al4l/pfzwm20s e5afW8veqzd+iTp6ihARrLmomM8DyzuSzi99yiWtnpcZ5b6VPqcCf+WvwbqQSq5QODCr Xpk9b4lg6wIwVjPSWyaNQUpGdxJBLXiJr0+yB/y1tsEvi7F+Yqw2DSdyC0ahHymDntoe SBHTdJVrcq9TZfltGNj3IceDIRR9OtZbvUzkxYUV3nuCVsc5wnbcwKaTDqRkhGKkW8r/ qDZ8a9fXDau4rrfMXFGuSmqrLm5PMysf2G7kyT2GCifHUymvHFyCmWEQT2TcUT+Mq5Dr QJJw==
X-Gm-Message-State: ALoCoQkwXyh0/VAcf6voS5rA9q2TyuHnNO5gl77VsWAfM8zsM3ADEN9KYepNl2V/xLqAexlqocSW
X-Received: by 10.194.191.163 with SMTP id gz3mr4527556wjc.114.1414776932863;  Fri, 31 Oct 2014 10:35:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Fri, 31 Oct 2014 10:34:52 -0700 (PDT)
In-Reply-To: <544FC339.8010605@polarssl.org>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz>  <544F635D.2000309@polarssl.org> <20141028145223.GQ19158@mournblade.imrryr.org> <544FC339.8010605@polarssl.org>
From: Eric Rescorla 
Date: Fri, 31 Oct 2014 10:34:52 -0700
Message-ID: 
To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= 
Content-Type: multipart/alternative; boundary=047d7ba97f2c8551b70506bb6c26
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sArF2ewHN_zAnLDYnCnmtue0Rps
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 17:35:37 -0000

--047d7ba97f2c8551b70506bb6c26
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This discussion seems to be settling, so I've prepared a pull request
that implements Bodo's suggestion:

https://github.com/tlswg/tls13-spec/pull/86

-Ekr


On Tue, Oct 28, 2014 at 9:24 AM, Manuel P=C3=A9gouri=C3=A9-Gonnard 
wrote:

> On 28/10/2014 15:52, Viktor Dukhovni wrote:
> > On Tue, Oct 28, 2014 at 10:35:25AM +0100, Manuel P?gouri?-Gonnard wrote=
:
> >
> >> On 27/10/2014 23:10, Eric Rescorla wrote:
> >>> As I said above, I'm principally trying to get rid of negotiation so
> we have
> >>> one point format for each curve. I could certainly live with requirin=
g
> >>> uncompressed only for the X9.62 curves and then defining a new, clean=
er
> >>> format for the new CFRG curves.
> >>
> >> If the goal is to get rid of negotiation, would it be reasonable to sa=
y
> that
> >> implementations MUST support both formats?
> >
> > I think that Bodo's suggestion of separate IANA assignments for
> > compressed and uncompressed variants of curves makes the most sense.
> >
> Yes, I didn't see his suggestion when I posted, but now I agree it looks
> like
> the best way to go.
>
> Manuel.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7ba97f2c8551b70506bb6c26
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


This discussion seems to be settling, so I've prepared=
 a pull request=C2=A0
that implements Bodo's suggestion:

-Ekr


On Tue, Oct 28, 2014 at 9:24 AM, Manuel P=C3=A9gouri=C3=A9=
-Gonnard <mpg@polarssl.org> wrote:
On 28/10/2014 15:52, Viktor Dukhovni wrote:

> On Tue, Oct 28, 2014 at 10:35:25AM +0100, Manuel P?gouri?-Gonnard wrot=
e:

>

>> On 27/10/2014 23:10, Eric Rescorla wrote:

>>> As I said above, I'm principally trying to get rid of nego=
tiation so we have

>>> one point format for each curve. I could certainly live with r=
equiring

>>> uncompressed only for the X9.62 curves and then defining a new=
, cleaner

>>> format for the new CFRG curves.

>>

>> If the goal is to get rid of negotiation, would it be reasonable t=
o say that

>> implementations MUST support both formats?

>

> I think that Bodo's suggestion of separate IANA assignments for
> compressed and uncompressed variants of curves makes the most sense.
>

Yes, I didn't see his suggestion when I posted, but now I agree =
it looks like

the best way to go.



Manuel.




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--047d7ba97f2c8551b70506bb6c26--


From nobody Fri Oct 31 10:55:39 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63B91A00B5 for ; Fri, 31 Oct 2014 10:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.041
X-Spam-Level: *
X-Spam-Status: No, score=1.041 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlo9wAPVAX5z for ; Fri, 31 Oct 2014 10:55:35 -0700 (PDT)
Received: from BLU004-OMC2S14.hotmail.com (blu004-omc2s14.hotmail.com [65.55.111.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DAF41A02F1 for ; Fri, 31 Oct 2014 10:55:33 -0700 (PDT)
Received: from BLU177-W52 ([65.55.111.73]) by BLU004-OMC2S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Fri, 31 Oct 2014 10:55:32 -0700
X-TMN: [LWVls33p6/D43Vsg6pEeg59O4b2Oftek]
X-Originating-Email: [yuhongbao_386@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_930d85b1-0208-495d-9b43-986a821c2a8f_"
From: Yuhong Bao 
To: Watson Ladd , Bodo Moeller 
Date: Fri, 31 Oct 2014 10:55:32 -0700
Importance: Normal
In-Reply-To: 
References: , <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp>, , , 
MIME-Version: 1.0
X-OriginalArrivalTime: 31 Oct 2014 17:55:32.0830 (UTC) FILETIME=[DDAD67E0:01CFF533]
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BX5bdXsplIxWX357AhpyOB2bY_k
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 17:55:36 -0000

--_930d85b1-0208-495d-9b43-986a821c2a8f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> The question is not why SSL v3 got it wrong. The question is why we
> didn't get it right a few years later=2C and stop using broken
> protocols. You wrote in 2004 that one byte could be extracted from a
> SSL v3 ciphertext=2C thus breaking confidentiality completely. Yet it's
> not until 2014 that this actually leads to action on depreciating SSL
> v3.
Ah=2C back in 2004 most browsers still comes with SSLv2 enabled by default.=
TLS 1.0 was barely five years old.IE6 was the dominant browser and it came =
with TLS 1.0 disabled by default.It wasn't until late 2006 that Firefox 2.0=
 and IE7 was released that disabled SSLv2.SSLv2 had much worse security fla=
ws than SSLv3 did.
Yuhong Bao 		 	   		  =

--_930d85b1-0208-495d-9b43-986a821c2a8f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





>=3B The question is not why SSL v3 got it wrong. The question is wh=
y we
>=3B didn't get it right a few years later=2C and sto=
p using broken
>=3B protocols. You wrote in 2004 that one byte could b=
e extracted from a
>=3B SSL v3 ciphertext=2C thus breaking confidentia=
lity completely. Yet it's
>=3B not until 2014 that this actually leads=
 to action on depreciating SSL
>=3B v3.
Ah=2C back in 2004 most bro=
wsers still comes with SSLv2 enabled by default.
TLS 1.0 was bare=
ly five years old.
IE6 was the dominant browser and it came with =
TLS 1.0 disabled by default.
It wasn't until late 2006 that Firef=
ox 2.0 and IE7 was released that disabled SSLv2.
SSLv2 had much w=
orse security flaws than SSLv3 did.

Yuhong Bao 		 	   		  

=

--_930d85b1-0208-495d-9b43-986a821c2a8f_--


From nobody Fri Oct 31 11:32:00 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB24F1A0AF1 for ; Fri, 31 Oct 2014 11:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqHJ5YjvTHqv for ; Fri, 31 Oct 2014 11:31:56 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF281A19F3 for ; Fri, 31 Oct 2014 11:31:49 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id D9D7A9002B; Fri, 31 Oct 2014 20:31:46 +0200 (EET)
Date: Fri, 31 Oct 2014 20:31:46 +0200
From: Ilari Liusvaara 
To: Eric Rescorla 
Message-ID: <20141031183146.GA12592@LK-Perkele-VII>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz>  <544F635D.2000309@polarssl.org> <20141028145223.GQ19158@mournblade.imrryr.org> <544FC339.8010605@polarssl.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TqjcbLPXMQPSZEmhu5W5LFu0iw4
Cc: Manuel =?utf-8?B?UMOpZ291cmnDqS1Hb25uYXJk?= , "tls@ietf.org" 
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 18:31:58 -0000

On Fri, Oct 31, 2014 at 10:34:52AM -0700, Eric Rescorla wrote:
> This discussion seems to be settling, so I've prepared a pull request
> that implements Bodo's suggestion:
> 
> https://github.com/tlswg/tls13-spec/pull/86
 
I think 8.1.2 (ECDHE premaster secret calculation) should be modified
as well, to specify using the fixed wire encoding of selected group for
premaster secret.

This is to avoid problems with more "odd" encodings.


Note that 8.1.1 does not quite match that beheviour, since it specifes
leading zero octets to be stripped (whereas DHE "element" encoding
doesn't seem to specify if zeroes are stripped or not)


-Ilari


From nobody Fri Oct 31 12:04:47 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB871A1A40 for ; Fri, 31 Oct 2014 12:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m48u_HY91Pgl for ; Fri, 31 Oct 2014 12:04:39 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FEE41A1A12 for ; Fri, 31 Oct 2014 12:04:39 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id l18so8640045wgh.10 for ; Fri, 31 Oct 2014 12:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vSa5BBhVij41qI1rPf9SiAkMtjJ4mQA/lvDsNZBsp7w=; b=gAOmDtM3HPAPJyfr5fHrNi8sMkL/uxY5MHIkbVDVHZwjOc8I6Ann4EV+qALn19ILQv Ko4Ev8yiY6jOBEryY7LkCPtAXxPn+i4Z+GBkhA+UxEKzZUntHmTQKdKM9XJHwgLrxoG+ Nyg1eiUncA4FUpstu7f2rhVnlv3paH65HQbuYL6MUWvlJBAxajNqgEzUvo61xr4d9swG rq4MpTdlTbWFNOkbYr3hgwn8wauiEVv5Ikttm4XuAlLab3XJNLLe9S93GPpOeMKwGZvf NQDMPCGpVG5BvldavA25J8Pym5I7yQ9Qdv2QVIQ+v6DvsKAW//YCfKovU2XSi/WN9Zs+ ZpaA==
X-Received: by 10.194.90.175 with SMTP id bx15mr29312805wjb.25.1414782277954;  Fri, 31 Oct 2014 12:04:37 -0700 (PDT)
Received: from [192.168.1.104] (IGLD-84-228-87-161.inter.net.il. [84.228.87.161]) by mx.google.com with ESMTPSA id eu8sm2594111wic.1.2014.10.31.12.04.37 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 12:04:37 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DD118FB6-0B34-40B7-8917-0A9CF6AABC58"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir 
In-Reply-To: 
Date: Fri, 31 Oct 2014 21:04:35 +0200
Message-Id: <98C3E3E6-5BB1-49E0-BF5F-D5378E3D8688@gmail.com>
References:  <, > <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp> <, >  <, >  <, >  
To: Yuhong Bao 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nYPaJWKXKGBMGi4BA_6MWRdxj3U
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 19:04:45 -0000

--Apple-Mail=_DD118FB6-0B34-40B7-8917-0A9CF6AABC58
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=iso-8859-1


> On Oct 31, 2014, at 7:55 PM, Yuhong Bao  wrote:
> 
> SSLv2 had much worse security flaws than SSLv3 did.

Other than the downgrade attack by a MITM, what else?


--Apple-Mail=_DD118FB6-0B34-40B7-8917-0A9CF6AABC58
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1


On Oct 31, 2014, at 7:55 PM, Yuhong Bao <yuhongbao_386@hotmail.com> wrote:

SSLv2 had much worse security flaws than SSLv3 did.

Other than the downgrade attack by a MITM, what else?


--Apple-Mail=_DD118FB6-0B34-40B7-8917-0A9CF6AABC58--


From nobody Fri Oct 31 16:46:41 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8251A70E1 for ; Fri, 31 Oct 2014 02:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS8suoZT4vcn for ; Fri, 31 Oct 2014 02:02:03 -0700 (PDT)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342FA1A797C for ; Fri, 31 Oct 2014 02:02:03 -0700 (PDT)
Received: by mail-qg0-f54.google.com with SMTP id q108so5195673qgd.41 for ; Fri, 31 Oct 2014 02:02:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:message-id; bh=jjhxYkykHW0HS1yVvr/f22kDh1C0lJPi4zTmTUAtM28=; b=DI0bD5jl1FVoyrCUpuSNzMsf6jGr4PKFLqSa86ZroLSZpET+3XkjII+WDMYchdz+bl X8UB1tuxpfUkQUZXRwMOyKjl9evInQWn2ah5zbI+rQKend5lnC8CDRDxKn/rifg4jI03 lv/PgGVHpHh9YdOHtHJP7VlUuWALjXbcEO7fOtRNs0PE9P//L/EGGOrcadYAu2B5nbwi apty4O32eLglnM2H5j7tljdTXUU1snSGYHQmOlXRENCXTd+xE1syARLbYLWHd4LlC2UK cyiTAwdgmKI9PMrB4xg1xcrm/dYN3UIQ0hB489cUcBpUvMa9eXOW/qTP/VNY/L6MdZyi uHTw==
X-Received: by 10.224.50.84 with SMTP id y20mr34766148qaf.44.1414746122374; Fri, 31 Oct 2014 02:02:02 -0700 (PDT)
Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id i33sm8940502qgd.8.2014.10.31.02.02.02 for  (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 31 Oct 2014 02:02:02 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org
Date: Fri, 31 Oct 2014 05:02:00 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201410310502.01198.davemgarrett@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/r9HyAkJW43BDhok7mbBDaBV9PVU
X-Mailman-Approved-At: Fri, 31 Oct 2014 16:46:34 -0700
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 09:02:05 -0000

Martin Rex wrote:
> [...] TLS is not designed to provide protection from [...]

This is not a useful debate. What SSL/TLS was designed to do last millennium is irrelevant. We have new threat models now and have to adapt our expectations of security protocols to deal with them.

https://www.youtube.com/watch?v=MiU42KI1GUw#t=110s

There's no point in arguing about SSL3 at this point. Even if it's theoretically safe with various mitigations within a narrow use-case, very few people trust it anymore. It's archaic and long since deprecated. TLS 1.0 is obsolete for that matter. If security is the actual goal here, it really should be TLS 1.2 or bust by now. The only reason any of these old versions are supported is an unwillingness/incapability of vendors to properly coordinate upgrades and deprecations. It took a decade and a half and POODLE to get anybody to jointly axe SSL3. We should take it as good that we can move slightly into the future and move on.

I'd like to see a draft for prohibiting TLS 1.0 on the queue next. If we've learned one thing recently, it's that you shouldn't wait until the last possible moment to get rid of old protocols. We shouldn't be expecting old versions to be maintained properly with all necessary mitigations that are required, nor should we be surprised when they inevitably have some long standing flaw that eventually gets discovered.


-- Dave


From nobody Fri Oct 31 16:47:07 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A8C1A8742 for ; Fri, 31 Oct 2014 16:47:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNu_nubXeAA7 for ; Fri, 31 Oct 2014 16:47:02 -0700 (PDT)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C6F1A8749 for ; Fri, 31 Oct 2014 16:47:02 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id x19so2314954ier.2 for ; Fri, 31 Oct 2014 16:47:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MyYsbsXz+st+Y9wOzqz9yJJ6Yv3MK95djrcZABrlqrw=; b=D3buTS+mXgybdNhs3ErsNVzifC2ZFFvJm/fyG25o61jknr02ZwN6gVmIAVgTA0conN NVdu/G0SOk+IOyWIOeU9FUp9SgRCEkVwoNIufqQYACU2YzegkpR27nARhkvl7oyBRx13 hdPLhu1LpeJ2kvvHduH8AUQLt77cfyZx4xR9zBT9gpecfUaDdD9I2SFa0ftQsm9anGhE fP88FJL8xiuYpYZMvBNkRkwzcr1EsAuOYHBWgvymXQNSxlKPWt+6boedCu3/keYhzOjT CUSklx9BYEvY7xkl1mo0gPKkHM0WaflGg1GxCGu8X9Hyqp9FubF04BGu04dkkYc3doG4 gl+w==
MIME-Version: 1.0
X-Received: by 10.50.134.131 with SMTP id pk3mr485148igb.6.1414799220758; Fri, 31 Oct 2014 16:47:00 -0700 (PDT)
Received: by 10.107.134.194 with HTTP; Fri, 31 Oct 2014 16:47:00 -0700 (PDT)
In-Reply-To: <98C3E3E6-5BB1-49E0-BF5F-D5378E3D8688@gmail.com>
References:  <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp>     <98C3E3E6-5BB1-49E0-BF5F-D5378E3D8688@gmail.com>
Date: Fri, 31 Oct 2014 16:47:00 -0700
Message-ID: 
From: Jeffrey Walton 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-JZfe_WOB-Jv7iheVKZx2MoK9Aw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 23:47:04 -0000

On Fri, Oct 31, 2014 at 12:04 PM, Yoav Nir  wrote:
>
> On Oct 31, 2014, at 7:55 PM, Yuhong Bao  wrote:
>
> SSLv2 had much worse security flaws than SSLv3 did.
>
>
> Other than the downgrade attack by a MITM, what else?
>

"Differences Between SSLv2, SSLv3, and TLS",
http://yaksman.org/~lweith/ssl.pdf. There's three or four pages of
problems enumerated by Weith.


From nobody Fri Oct 31 17:54:46 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7191A8763 for ; Fri, 31 Oct 2014 17:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.023
X-Spam-Level: **
X-Spam-Status: No, score=2.023 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RYVKMdNCuwx for ; Fri, 31 Oct 2014 17:54:41 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD6F1A8760 for ; Fri, 31 Oct 2014 17:54:40 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id q1so7095151lam.38 for ; Fri, 31 Oct 2014 17:54:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:from:date:message-id:subject:to:cc:content-type;  bh=z1+iO5mPaPAhY0dSHG6L064XJu7zXTUQjG7EKw0hXb8=; b=K4u9UwKXnmlWmUrvkT5ZRE49vEIcxHtyssCce0s2EUlyn12oJFKYHJaJUVHOts7/0T eGY1/+Ey26CCPQ2BFv0dRDrmj2Wl61DsYVCVhVdT5YrJgryceQHMGZ7YO+imJ3nuqcos DnsNYrHz/ZzOl9H47prDk5jOB5p74ivxUOd0x1wIM4QxBgAY9vM/5t9B7GvM3CRwyjfo QEdqBj3pqoOytT+AYcUM3D+014I65owoqde6PoAZAqlL5tBtfTtCdpJP3TxC8w5rz4Lp YOxkk8rUZXY9dDe90TAolqbLOb5P3fEV/L84/jIv21Adnqrss6O5P+7gy5gY4nfqfU5l NUMw==
X-Received: by 10.112.85.138 with SMTP id h10mr30102361lbz.33.1414803278824; Fri, 31 Oct 2014 17:54:38 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.25.78.20 with HTTP; Fri, 31 Oct 2014 17:54:08 -0700 (PDT)
From: Hugo Krawczyk 
Date: Sat, 1 Nov 2014 02:54:08 +0200
X-Google-Sender-Auth: HYkLVY5U2ry9Qc5RnOQUbgCf65A
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11347168dc8ddc0506c18ed0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ma_T1AL5_jMarTB8Ci0vdfYCoVM
Cc: Hoeteck Wee 
Subject: [TLS] OPTLS: Signature-less TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Nov 2014 00:54:45 -0000

--001a11347168dc8ddc0506c18ed0
Content-Type: text/plain; charset=UTF-8

During the TLS interim meeting of last week (Oct 22 2014) I suggested that
TLS
1.3 should abandon signature-based authentication (other than for
certificates)
and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
static Diffie-Hellman for authentication. This has multiple benefits
including
major performance gain (by replacing the per-handshake RSA signature by the
server with a much cheaper elliptic curve exponentiation), compatibility
with
the mechanisms required for forward secrecy, natural accommodation of a
0-RTT
option, and a simple extension without signatures for client authentication.

Below I present a schematic representation of the proposed protocol referred
to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three.
The presentation is sketchy and omits the exact procedure for key
derivation.
The latter is a crucial component for the security of the protocol, but
before getting into these details we want to get a sense of whether the WG
is
interested in this approach. In the meantime, Hoeteck Wee and myself are
working on the details of the protocol and the security proof.

We describe a setting with optional 0-RTT and server-only authentication.
Client authentication can be added as a further option or as an extension
(similar to the current 1.3 proposal) - see below.

NOTATION AND TERMINOLOGY:

[K] symbols represent pointers to key material whose exact derivation is not
included here except for specifying the basic DH values from which the key
is
derived (actual derivation will include further information similar to the
extended hash mechanisms or SessionHash proposal considered for 1.3).
Asterisks represent optional fields that the WG can decide to leave as
optional,
mandatory, or simply remove without changing the core cryptographic
security of
the protocol. All references to encryption mean "authenticated encryption"
using the encrypt-then-mac paradigm (or any other secure AEAD mechanism).

KeyShare's represent ephemeral Diffie-Hellman values exchanged by the
parties.
All the public key and Diffie-Hellman operations are assumed to happen over
a
cyclic group with generator g of order q (typically implemented by an
elliptic
curve group). We use multiplicative notation where ^ denotes exponentiation
as
in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y), etc.
Omitted from the current high level description is a mechanism for testing
group
membership of DH values or cofactor exponentiation (the specific mechanism
depends on the group type and is typically very efficient for elliptic
curves).

SERVER PUBLIC KEY AND CERTIFICATE:

The server has a long term private-public key pair denoted by (s,g^s) where
s is uniform random in [0..q-1] (we refer to s and g^s as "static keys").
We assume that the server has a certificate that includes the server's
public
key g^s and a CA-signed binding of this key to the server's identity.
We discuss the implementation of such certificates below.

PROTOCOL OPTLS:

ClientHello
ClientKeyShare
ClientData* [K0]       -------->
                                           ServerHello
                                           ServerKeyShare
                                           ServerCertificate* [K1]
                                           ServerFinished [K2]
                       <--------           ServerData* [K2]
ClientFinished* [K2]   -------->


            Protected Application Data [K3]
                       <------->



1-RTT CASE:

The basic 1-RTT case omits the ClientData* field. It includes a
ClientKeyShare
g^x and a ServerKeyShare g^y and an optional (encrypted) server
certificate.
If the certificate is sent (it can be omitted if the client has indicated
that
it knows the server key as in the case in the 0-RTT scenario) and is
encrypted,
the encryption key K1 is derived from g^{xy}.

Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is used
to
authenticate-encrypt the ServerFinished and ClientFinished messages (which
include a hash of the previous traffic) and to encrypt data from the server
if
such data is piggybacked to the second message.

Key K3 is the "application key" used to derive key material for protection
of
application data.  This key material will include (directional)
Authenticated
Encryption keys and, possibly, keys for derivation of further re-key
material.
K3 is computed from  both g^{xs} and g^{xy} similarly to K2, but its
derivation
will be different than K2, e.g., using a separating key expansion technique.

SUPPORT FOR 0-RTT:

The above protocol is compatible with a 0-RTT protocol such as QUIC. In this
case, the client is assumed to have information about the server's public
key
and other security parameters. The server is assumed to have some mechanism
in
place for detecting replay (e.g., via timestamps, stored client nonces,
etc.).
The resulting protocol is as described above where the ClientData field is
sent
encrypted under key K0 derived from g^{xs}.
The rest of the protocol is identical to the above.
Note: In this case, ServerCertificate is not sent as the client had to know
the server's public key before the first message (one can imagine a setting
where the server may send a different certificate in the second message - if
desired, this can be accommodated too as an option or extension).

CLIENT AUTHENTICATION:

Client authentication can be supported via an option or extension. It would
include a client certificate for a static DH key g^c sent in the third
message
(the certificate can be encrypted under key K2 to provide client's identity
protection). In this case, the key for computing the ClientFinished message
and
the application key K3 would be derived from a combination of the values
g^xy,
g^xs, g^yc (and possibly also g^{cs}).

NOTES:

Note on Finished messages: The above spec sets ServerFinished as mandatory
and
ClientFinished as optional. The latter option is needed for a 1-RTT
protocol.
In principle, both Finished messages could be omitted and still obtain
security
via implicit authentication (assuming the inputs to key derivation are
chosen
appropriately). But given the advantages of ServerFinished for providing
explicit authentication, key confirmation, and active forward secrecy (see
below), it seems advisable to always include it. Including ClientFinished
provides key confirmation from client and also explicit client
authentication
when client certificate is included. ClientFinished also provides Universal
Composable (UC) security (this is a result of the Canetti-Krawczyk proof
that
CK security implies UC security when a client confirmation step is
included).

Note on certificates: Since in current practice servers hold certificates
for
RSA signature keys rather than for static DH keys, the certificate field in
the
above protocol will be implemented by a pair consisting of (i) the server's
RSA
signature certificate and (ii) the server's signature using this RSA key on
the
server's static public DH key g^s. The latter signature by the server is
performed only when a new static DH key is created (how often this happens
and
how many such keys are created is completely up to the server - it has the
advantage that these keys can be changed often to increase security against
leaked keys). This use of RSA also enjoys the high efficiency of RSA
verification for the client.
The handling of Client certificates would be similar.

Note on forward security (a.k.a. as PFS for Perfect Forward Security):
PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys.
The meaning of PFS is that an attacker that finds the (long-term) static
private keys of the parties cannot compromise past session keys. Without the
ServerFinished message the above protocol ensures forward secrecy against
passive attackers (i.e., for sessions where the attacker did not choose
g^y).
With ServerFinished, PFS holds also against active attackers.  A similar
consideration applies to ClientFinished.

Client certificates in the first message: We note that in cases where client
certificates can be sent in the clear in the first message of the protocol,
one
can provide PFS and mutual authentication in a 1-RTT at essentially the same
cost of an unauthenticated DH exchange (i.e., a cost of little more than two
exponentiations). In such a setting one can also obtain mutual
authentication in
a 0-RTT protocol (with forward secrecy with respect to the client's key).
These options, however, require HMQV-like mechanisms and may raise IP
issues (this
can be investigated further if the WG is interested).

--001a11347168dc8ddc0506c18ed0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


During the TLS interim meeting of last week (Oc=
t 22 2014) I suggested that TLS
1.3 should abandon signature-based authe=
ntication (other than for certificates)
and be based solely on a combina=
tion of ephemeral Diffie-Hellman for PFS and
static Diffie-Hellman for a=
uthentication. This has multiple benefits including
major performance ga=
in (by replacing the per-handshake RSA signature by the
server with a mu=
ch cheaper elliptic curve exponentiation), compatibility with
the mechan=
isms required for forward secrecy, natural accommodation of a 0-RTT
opti=
on, and a simple extension without signatures for client authentication.
Below I present a schematic representation of the proposed protocol re=
ferred
to as OPTLS where OPT stands for OPTimized and/or for One-Point-T=
hree.=C2=A0 
The presentation is sketchy and omits the exact procedure f=
or key derivation.
The latter is a crucial component for the security of=
 the protocol, but 
before getting into these details we want to get a s=
ense of whether the WG is
interested in this approach. In the meantime, =
Hoeteck Wee and myself are 
working on the details of the protocol and t=
he security proof.

We describe a setting with optional 0-RTT and ser=
ver-only authentication.
Client authentication can be added as a further=
 option or as an extension
(similar to the current 1.3 proposal) - see b=
elow.

NOTATION AND TERMINOLOGY:

[K] symbols represent pointer=
s to key material whose exact derivation is not
included here except for=
 specifying the basic DH values from which the key is
derived (actual de=
rivation will include further information similar to the
extended hash m=
echanisms or SessionHash proposal considered for 1.3). 
Asterisks repres=
ent optional fields that the WG can decide to leave as optional,
mandato=
ry, or simply remove without changing the core cryptographic security ofthe protocol. All references to encryption mean "authenticated encryp=
tion"
using the encrypt-then-mac paradigm (or any other secure AEAD=
 mechanism).=C2=A0 

KeyShare's represent ephemeral Diffie-Hellma=
n values exchanged by the parties.
All the public key and Diffie-Hellman=
 operations are assumed to happen over a
cyclic group with generator g o=
f order q (typically implemented by an elliptic
curve group). We use mul=
tiplicative notation where ^ denotes exponentiation as
in g^x, g^{xy} (h=
ere xy denotes multiplication of the scalars x and y), etc.
Omitted from=
 the current high level description is a mechanism for testing group
mem=
bership of DH values or cofactor exponentiation (the specific mechanism
=
depends on the group type and is typically very efficient for elliptic curv=
es).

SERVER PUBLIC KEY AND CERTIFICATE:

The server has a long=
 term private-public key pair denoted by (s,g^s) where 
s is uniform ran=
dom in [0..q-1] (we refer to s and g^s as "static keys"). 
We =
assume that the server has a certificate that includes the server's pub=
lic
key g^s and a CA-signed binding of this key to the server's iden=
tity.
We discuss the implementation of such certificates below.

P=
ROTOCOL OPTLS:

ClientHello
ClientKeyShare 
ClientData* [K0]=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -------->
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 ServerHello=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerKeyShare=
=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerCertificate* [K1]
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 ServerFinished [K2]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 <--------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerData* [K2]
ClientFinished* [K2]=C2=A0=
=C2=A0 -------->


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 Protected Application Data [K3]
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <------->



1=
-RTT CASE:

The basic 1-RTT case omits the ClientData* field. It incl=
udes a ClientKeyShare
g^x and a ServerKeyShare g^y and an optional (encr=
ypted) server certificate. 
If the certificate is sent (it can be omitte=
d if the client has indicated that
it knows the server key as in the cas=
e in the 0-RTT scenario) and is encrypted,
the encryption key K1 is deri=
ved from g^{xy}.

Key K2 is an encryption key derived from both g^{xs=
} and g^{xy}. It is used to
authenticate-encrypt the ServerFinished and =
ClientFinished messages (which
include a hash of the previous traffic) a=
nd to encrypt data from the server if
such data is piggybacked to the se=
cond message.

Key K3 is the "application key" used to deri=
ve key material for protection of
application data.=C2=A0 This key mater=
ial will include (directional) Authenticated
Encryption keys and, possib=
ly, keys for derivation of further re-key material.
K3 is computed from=
=C2=A0 both g^{xs} and g^{xy} similarly to K2, but its derivation
will b=
e different than K2, e.g., using a separating key expansion technique.
<=
br>SUPPORT FOR 0-RTT: 

The above protocol is compatible with a 0-RTT=
 protocol such as QUIC. In this
case, the client is assumed to have info=
rmation about the server's public key
and other security parameters.=
 The server is assumed to have some mechanism in
place for detecting rep=
lay (e.g., via timestamps, stored client nonces, etc.).
The resulting pr=
otocol is as described above where the ClientData field is sent
encrypte=
d under key K0 derived from g^{xs}.=C2=A0 
The rest of the protocol is i=
dentical to the above.=C2=A0 
Note: In this case, ServerCertificate is n=
ot sent as the client had to know
the server's public key before the=
 first message (one can imagine a setting
where the server may send a di=
fferent certificate in the second message - if
desired, this can be acco=
mmodated too as an option or extension).

CLIENT AUTHENTICATION: 
=

Client authentication can be supported via an option or extension. It w=
ould
include a client certificate for a static DH key g^c sent in the th=
ird message 
(the certificate can be encrypted under key K2 to provide c=
lient's identity
protection). In this case, the key for computing th=
e ClientFinished message and
the application key K3 would be derived fro=
m a combination of the values g^xy,
g^xs, g^yc (and possibly also g^{cs}=
). 

NOTES:

Note on Finished messages: The above spec sets Ser=
verFinished as mandatory and
ClientFinished as optional. The latter opti=
on is needed for a 1-RTT protocol.
In principle, both Finished messages =
could be omitted and still obtain security
via implicit authentication (=
assuming the inputs to key derivation are chosen
appropriately). But giv=
en the advantages of ServerFinished for providing
explicit authenticatio=
n, key confirmation, and active forward secrecy (see
below), it seems ad=
visable to always include it. Including ClientFinished
provides key conf=
irmation from client and also explicit client authentication
when client=
 certificate is included. ClientFinished also provides Universal
Composa=
ble (UC) security (this is a result of the Canetti-Krawczyk proof that 
=
CK security implies UC security when a client confirmation step is included=
).=C2=A0 

Note on certificates: Since in current practice servers ho=
ld certificates for
RSA signature keys rather than for static DH keys, t=
he certificate field in the
above protocol will be implemented by a pair=
 consisting of (i) the server's RSA
signature certificate and (ii) t=
he server's signature using this RSA key on the
server's static =
public DH key g^s. The latter signature by the server is
performed only =
when a new static DH key is created (how often this happens and
how many=
 such keys are created is completely up to the server - it has the
advan=
tage that these keys can be changed often to increase security against
l=
eaked keys). This use of RSA also enjoys the high efficiency of RSA
veri=
fication for the client.=C2=A0 
The handling of Client certificates woul=
d be similar.

Note on forward security (a.k.a. as PFS for Perfect Fo=
rward Security): 
PFS is provided by the (mandatory) use of ephemeral Di=
ffie-Hellman keys.
The meaning of PFS is that an attacker that finds the=
 (long-term) static
private keys of the parties cannot compromise past s=
ession keys. Without the
ServerFinished message the above protocol ensur=
es forward secrecy against
passive attackers (i.e., for sessions where t=
he attacker did not choose g^y).
With ServerFinished, PFS holds also aga=
inst active attackers.=C2=A0 A similar
consideration applies to ClientFi=
nished.

Client certificates in the first message: We note that in ca=
ses where client
certificates can be sent in the clear in the first mess=
age of the protocol, one
can provide PFS and mutual authentication in a =
1-RTT at essentially the same
cost of an unauthenticated DH exchange (i.=
e., a cost of little more than two
exponentiations). In such a setting o=
ne can also obtain mutual authentication in
a 0-RTT protocol (with forwa=
rd secrecy with respect to the client's key).=C2=A0 
These options, =
however, require HMQV-like mechanisms and may raise IP issues (this
can =
be investigated further if the WG is interested).



--001a11347168dc8ddc0506c18ed0--


From nobody Fri Oct 31 18:45:23 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EF81A877E for ; Fri, 31 Oct 2014 18:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.023
X-Spam-Level: 
X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmPO_m3YBIdJ for ; Fri, 31 Oct 2014 18:45:18 -0700 (PDT)
Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC5A51A877B for ; Fri, 31 Oct 2014 18:45:17 -0700 (PDT)
Received: by mail-wg0-f53.google.com with SMTP id b13so7670657wgh.12 for ; Fri, 31 Oct 2014 18:45:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=boMmaZ9V2U1RKdOKLgp5MzDuyvjYP1YhG9H1gKNU0Qw=; b=gqs1CI74nUL4EFm6OwH6i/Tf2cdxY81dbdSW7K56VF0SS40kniB5p8FJbEx+JHNA5x 1GKL9UcM3DbQmQdaW5xGYgzjN2Ynf/sQZZo0GfTjPyTMJ4/6dwt4rRY94Ug+UCIUOQ5T TCfgcY+kYOPlCk87s9ogHYffLZon36DaneFZsvZ/Djxsipe1NRpM23ObP8F5hdsUa1/h 9o5RheLXLrit0frXX0uTr6m8ysoXv0jgCGPLWx1ItkLA8hgjNce+z70ycYCNe7Nbukxp zINgzRQkQnRpZ6Bh3oczOD4DEq+ZTPIirEig+LDWeBGbd3RPuu7TSyOuH15ZNyPiUr9i 9ObQ==
X-Gm-Message-State: ALoCoQlG/ZFafOKSjCjRHaFFpEI9e8AE1GSfGfYNX0YfNJXkJ4Jb41pw5g3VMG/4uU4YR+xKiN+/
X-Received: by 10.180.103.233 with SMTP id fz9mr859309wib.80.1414806315990; Fri, 31 Oct 2014 18:45:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Fri, 31 Oct 2014 18:44:35 -0700 (PDT)
In-Reply-To: 
References: 
From: Eric Rescorla 
Date: Fri, 31 Oct 2014 18:44:35 -0700
Message-ID: 
To: Hugo Krawczyk 
Content-Type: multipart/alternative; boundary=f46d044280cae413f60506c24319
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uvKCG_0pqWS0Dk0JTjt_E3yB95Y
Cc: "tls@ietf.org" , Hoeteck Wee 
Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Nov 2014 01:45:22 -0000

--f46d044280cae413f60506c24319
Content-Type: text/plain; charset=UTF-8

Hugo,

Thanks for writing this up. I'm still digesting this, but I had a few
questions.

1. In the interim, I believe you suggested MAC of the transcript under
g^{xs} to authenticate g^y. This is fairly analogous to CertificateVerify,
except using a MAC rather than a signature. In the current design, you
instead generate a combined key from g^{xs] and g^{xy}. Are there
advantages to this design or is it just a matter of style?

2. I'm thinking about how to adapt this to PSK+PFS modes (i.e.,
where you want the PSK for authentication but you want to do
a DHE exchange for PFS). In the design you propose, it seems
like the analogous thing to do would be to treat the PSK like
g^{xy}? Does this interact at all with whether to mix the keys
or use a MAC?

3. WRT client auth, I think we've generally decided that the client's
certificate ought to be encrypted. Given that, I wonder if it would be
easier
for the client to just do a digital signature over the transcript and/or
an authenticator derived from the secret. Generally, the additional
cost of the RSA signature isn't a huge problem for most clients and
those which do should be able to quickly move to EC-based keys.

Thanks,
-Ekr


On Fri, Oct 31, 2014 at 5:54 PM, Hugo Krawczyk 
wrote:

> During the TLS interim meeting of last week (Oct 22 2014) I suggested that
> TLS
> 1.3 should abandon signature-based authentication (other than for
> certificates)
> and be based solely on a combination of ephemeral Diffie-Hellman for PFS
> and
> static Diffie-Hellman for authentication. This has multiple benefits
> including
> major performance gain (by replacing the per-handshake RSA signature by the
> server with a much cheaper elliptic curve exponentiation), compatibility
> with
> the mechanisms required for forward secrecy, natural accommodation of a
> 0-RTT
> option, and a simple extension without signatures for client
> authentication.
>
> Below I present a schematic representation of the proposed protocol
> referred
> to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three.
> The presentation is sketchy and omits the exact procedure for key
> derivation.
> The latter is a crucial component for the security of the protocol, but
> before getting into these details we want to get a sense of whether the WG
> is
> interested in this approach. In the meantime, Hoeteck Wee and myself are
> working on the details of the protocol and the security proof.
>
> We describe a setting with optional 0-RTT and server-only authentication.
> Client authentication can be added as a further option or as an extension
> (similar to the current 1.3 proposal) - see below.
>
> NOTATION AND TERMINOLOGY:
>
> [K] symbols represent pointers to key material whose exact derivation is
> not
> included here except for specifying the basic DH values from which the key
> is
> derived (actual derivation will include further information similar to the
> extended hash mechanisms or SessionHash proposal considered for 1.3).
> Asterisks represent optional fields that the WG can decide to leave as
> optional,
> mandatory, or simply remove without changing the core cryptographic
> security of
> the protocol. All references to encryption mean "authenticated encryption"
> using the encrypt-then-mac paradigm (or any other secure AEAD mechanism).
>
> KeyShare's represent ephemeral Diffie-Hellman values exchanged by the
> parties.
> All the public key and Diffie-Hellman operations are assumed to happen
> over a
> cyclic group with generator g of order q (typically implemented by an
> elliptic
> curve group). We use multiplicative notation where ^ denotes
> exponentiation as
> in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y),
> etc.
> Omitted from the current high level description is a mechanism for testing
> group
> membership of DH values or cofactor exponentiation (the specific mechanism
> depends on the group type and is typically very efficient for elliptic
> curves).
>
> SERVER PUBLIC KEY AND CERTIFICATE:
>
> The server has a long term private-public key pair denoted by (s,g^s)
> where
> s is uniform random in [0..q-1] (we refer to s and g^s as "static keys").
> We assume that the server has a certificate that includes the server's
> public
> key g^s and a CA-signed binding of this key to the server's identity.
> We discuss the implementation of such certificates below.
>
> PROTOCOL OPTLS:
>
> ClientHello
> ClientKeyShare
> ClientData* [K0]       -------->
>                                            ServerHello
>                                            ServerKeyShare
>                                            ServerCertificate* [K1]
>                                            ServerFinished [K2]
>                        <--------           ServerData* [K2]
> ClientFinished* [K2]   -------->
>
>
>             Protected Application Data [K3]
>                        <------->
>
>
>
> 1-RTT CASE:
>
> The basic 1-RTT case omits the ClientData* field. It includes a
> ClientKeyShare
> g^x and a ServerKeyShare g^y and an optional (encrypted) server
> certificate.
> If the certificate is sent (it can be omitted if the client has indicated
> that
> it knows the server key as in the case in the 0-RTT scenario) and is
> encrypted,
> the encryption key K1 is derived from g^{xy}.
>
> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is
> used to
> authenticate-encrypt the ServerFinished and ClientFinished messages (which
> include a hash of the previous traffic) and to encrypt data from the
> server if
> such data is piggybacked to the second message.
>
> Key K3 is the "application key" used to derive key material for protection
> of
> application data.  This key material will include (directional)
> Authenticated
> Encryption keys and, possibly, keys for derivation of further re-key
> material.
> K3 is computed from  both g^{xs} and g^{xy} similarly to K2, but its
> derivation
> will be different than K2, e.g., using a separating key expansion
> technique.
>
> SUPPORT FOR 0-RTT:
>
> The above protocol is compatible with a 0-RTT protocol such as QUIC. In
> this
> case, the client is assumed to have information about the server's public
> key
> and other security parameters. The server is assumed to have some
> mechanism in
> place for detecting replay (e.g., via timestamps, stored client nonces,
> etc.).
> The resulting protocol is as described above where the ClientData field is
> sent
> encrypted under key K0 derived from g^{xs}.
> The rest of the protocol is identical to the above.
> Note: In this case, ServerCertificate is not sent as the client had to know
> the server's public key before the first message (one can imagine a setting
> where the server may send a different certificate in the second message -
> if
> desired, this can be accommodated too as an option or extension).
>
> CLIENT AUTHENTICATION:
>
> Client authentication can be supported via an option or extension. It would
> include a client certificate for a static DH key g^c sent in the third
> message
> (the certificate can be encrypted under key K2 to provide client's identity
> protection). In this case, the key for computing the ClientFinished
> message and
> the application key K3 would be derived from a combination of the values
> g^xy,
> g^xs, g^yc (and possibly also g^{cs}).
>
> NOTES:
>
> Note on Finished messages: The above spec sets ServerFinished as mandatory
> and
> ClientFinished as optional. The latter option is needed for a 1-RTT
> protocol.
> In principle, both Finished messages could be omitted and still obtain
> security
> via implicit authentication (assuming the inputs to key derivation are
> chosen
> appropriately). But given the advantages of ServerFinished for providing
> explicit authentication, key confirmation, and active forward secrecy (see
> below), it seems advisable to always include it. Including ClientFinished
> provides key confirmation from client and also explicit client
> authentication
> when client certificate is included. ClientFinished also provides Universal
> Composable (UC) security (this is a result of the Canetti-Krawczyk proof
> that
> CK security implies UC security when a client confirmation step is
> included).
>
> Note on certificates: Since in current practice servers hold certificates
> for
> RSA signature keys rather than for static DH keys, the certificate field
> in the
> above protocol will be implemented by a pair consisting of (i) the
> server's RSA
> signature certificate and (ii) the server's signature using this RSA key
> on the
> server's static public DH key g^s. The latter signature by the server is
> performed only when a new static DH key is created (how often this happens
> and
> how many such keys are created is completely up to the server - it has the
> advantage that these keys can be changed often to increase security against
> leaked keys). This use of RSA also enjoys the high efficiency of RSA
> verification for the client.
> The handling of Client certificates would be similar.
>
> Note on forward security (a.k.a. as PFS for Perfect Forward Security):
> PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys.
> The meaning of PFS is that an attacker that finds the (long-term) static
> private keys of the parties cannot compromise past session keys. Without
> the
> ServerFinished message the above protocol ensures forward secrecy against
> passive attackers (i.e., for sessions where the attacker did not choose
> g^y).
> With ServerFinished, PFS holds also against active attackers.  A similar
> consideration applies to ClientFinished.
>
> Client certificates in the first message: We note that in cases where
> client
> certificates can be sent in the clear in the first message of the
> protocol, one
> can provide PFS and mutual authentication in a 1-RTT at essentially the
> same
> cost of an unauthenticated DH exchange (i.e., a cost of little more than
> two
> exponentiations). In such a setting one can also obtain mutual
> authentication in
> a 0-RTT protocol (with forward secrecy with respect to the client's key).
> These options, however, require HMQV-like mechanisms and may raise IP
> issues (this
> can be investigated further if the WG is interested).
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--f46d044280cae413f60506c24319
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hugo,

Thanks for writing this up. I'=
;m still digesting this, but I had a few
questions.
1. In the interim, I believe you suggested MAC of the transcrip=
t under
g^{xs} to authenticate g^y. This is fairly analogous to C=
ertificateVerify,
except using a MAC rather than a signature. In =
the current design, you
instead generate a combined key from g^{x=
s] and g^{xy}. Are there
advantages to this design or is it just =
a matter of style?

2. I'm thinking about =
how to adapt this to PSK+PFS modes (i.e.,
where you want the PSK =
for authentication but you want to do
a DHE exchange for PFS). In=
 the design you propose, it seems
like the analogous thing to do =
would be to treat the PSK like
g^{xy}? Does this interact at all =
with whether to mix the keys
or use a MAC?
=C2=A0=C2=A0=

3. WRT client auth, I think we've generally decided th=
at the client's
certificate ought to be encrypted. Given =
that, I wonder if it would be easier
for the client to just do a =
digital signature over the transcript and/or
an authenticator der=
ived from the secret. Generally, the additional
cost of the RSA s=
ignature isn't a huge problem for most clients and
those whic=
h do should be able to quickly move to EC-based keys.

<=
div>Thanks,
-Ekr


On Fri, Oct 31, 2014 at 5:54 PM, Hu=
go Krawczyk <hugo@ee.technion.ac.il> wrote:
During the TLS interim =
meeting of last week (Oct 22 2014) I suggested that TLS
1.3 should aband=
on signature-based authentication (other than for certificates)
and be b=
ased solely on a combination of ephemeral Diffie-Hellman for PFS and
sta=
tic Diffie-Hellman for authentication. This has multiple benefits including=

major performance gain (by replacing the per-handshake RSA signature by=
 the
server with a much cheaper elliptic curve exponentiation), compatib=
ility with
the mechanisms required for forward secrecy, natural accommod=
ation of a 0-RTT
option, and a simple extension without signatures for c=
lient authentication.

Below I present a schematic representation of =
the proposed protocol referred
to as OPTLS where OPT stands for OPTimize=
d and/or for One-Point-Three.=C2=A0 
The presentation is sketchy and omi=
ts the exact procedure for key derivation.
The latter is a crucial compo=
nent for the security of the protocol, but 
before getting into these de=
tails we want to get a sense of whether the WG is
interested in this app=
roach. In the meantime, Hoeteck Wee and myself are 
working on the detai=
ls of the protocol and the security proof.

We describe a setting wit=
h optional 0-RTT and server-only authentication.
Client authentication c=
an be added as a further option or as an extension
(similar to the curre=
nt 1.3 proposal) - see below.

NOTATION AND TERMINOLOGY:

[K] s=
ymbols represent pointers to key material whose exact derivation is not
=
included here except for specifying the basic DH values from which the key =
is
derived (actual derivation will include further information similar t=
o the
extended hash mechanisms or SessionHash proposal considered for 1.=
3). 
Asterisks represent optional fields that the WG can decide to leave=
 as optional,
mandatory, or simply remove without changing the core cryp=
tographic security of
the protocol. All references to encryption mean &q=
uot;authenticated encryption"
using the encrypt-then-mac paradigm (=
or any other secure AEAD mechanism).=C2=A0 

KeyShare's represent=
 ephemeral Diffie-Hellman values exchanged by the parties.
All the publi=
c key and Diffie-Hellman operations are assumed to happen over a
cyclic =
group with generator g of order q (typically implemented by an elliptic
=
curve group). We use multiplicative notation where ^ denotes exponentiation=
 as
in g^x, g^{xy} (here xy denotes multiplication of the scalars x and =
y), etc.
Omitted from the current high level description is a mechanism =
for testing group
membership of DH values or cofactor exponentiation (th=
e specific mechanism
depends on the group type and is typically very eff=
icient for elliptic curves).

SERVER PUBLIC KEY AND CERTIFICATE:
<=
br>The server has a long term private-public key pair denoted by (s,g^s) wh=
ere 
s is uniform random in [0..q-1] (we refer to s and g^s as "sta=
tic keys"). 
We assume that the server has a certificate that inclu=
des the server's public
key g^s and a CA-signed binding of this key =
to the server's identity.
We discuss the implementation of such cert=
ificates below.

PROTOCOL OPTLS:

ClientHello
ClientKeyShare=
 
ClientData* [K0]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -------->
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerHello=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 ServerKeyShare=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerCerti=
ficate* [K1]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerFinished [K2]
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <--------=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerData* [K2]
Cli=
entFinished* [K2]=C2=A0=C2=A0 -------->


=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Protected Application Data [K=
3]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <-------=
>



1-RTT CASE:

The basic 1-RTT case omits the Clien=
tData* field. It includes a ClientKeyShare
g^x and a ServerKeyShare g^y =
and an optional (encrypted) server certificate. 
If the certificate is s=
ent (it can be omitted if the client has indicated that
it knows the ser=
ver key as in the case in the 0-RTT scenario) and is encrypted,
the encr=
yption key K1 is derived from g^{xy}.

Key K2 is an encryption key de=
rived from both g^{xs} and g^{xy}. It is used to
authenticate-encrypt th=
e ServerFinished and ClientFinished messages (which
include a hash of th=
e previous traffic) and to encrypt data from the server if
such data is =
piggybacked to the second message.

Key K3 is the "application k=
ey" used to derive key material for protection of
application data.=
=C2=A0 This key material will include (directional) Authenticated
Encryp=
tion keys and, possibly, keys for derivation of further re-key material.K3 is computed from=C2=A0 both g^{xs} and g^{xy} similarly to K2, but its =
derivation
will be different than K2, e.g., using a separating key expan=
sion technique.

SUPPORT FOR 0-RTT: 

The above protocol is com=
patible with a 0-RTT protocol such as QUIC. In this
case, the client is =
assumed to have information about the server's public key
and other =
security parameters. The server is assumed to have some mechanism in
pla=
ce for detecting replay (e.g., via timestamps, stored client nonces, etc.).=

The resulting protocol is as described above where the ClientData field=
 is sent
encrypted under key K0 derived from g^{xs}.=C2=A0 
The rest =
of the protocol is identical to the above.=C2=A0 
Note: In this case, Se=
rverCertificate is not sent as the client had to know
the server's p=
ublic key before the first message (one can imagine a setting
where the =
server may send a different certificate in the second message - if
desir=
ed, this can be accommodated too as an option or extension).

CLIENT =
AUTHENTICATION: 

Client authentication can be supported via an optio=
n or extension. It would
include a client certificate for a static DH ke=
y g^c sent in the third message 
(the certificate can be encrypted under=
 key K2 to provide client's identity
protection). In this case, the =
key for computing the ClientFinished message and
the application key K3 =
would be derived from a combination of the values g^xy,
g^xs, g^yc (and =
possibly also g^{cs}). 

NOTES:

Note on Finished messages: The=
 above spec sets ServerFinished as mandatory and
ClientFinished as optio=
nal. The latter option is needed for a 1-RTT protocol.
In principle, bot=
h Finished messages could be omitted and still obtain security
via impli=
cit authentication (assuming the inputs to key derivation are chosen
app=
ropriately). But given the advantages of ServerFinished for providing
ex=
plicit authentication, key confirmation, and active forward secrecy (seebelow), it seems advisable to always include it. Including ClientFinished<=
br>provides key confirmation from client and also explicit client authentic=
ation
when client certificate is included. ClientFinished also provides =
Universal
Composable (UC) security (this is a result of the Canetti-Kraw=
czyk proof that 
CK security implies UC security when a client confirmat=
ion step is included).=C2=A0 

Note on certificates: Since in current=
 practice servers hold certificates for
RSA signature keys rather than f=
or static DH keys, the certificate field in the
above protocol will be i=
mplemented by a pair consisting of (i) the server's RSA
signature ce=
rtificate and (ii) the server's signature using this RSA key on the
=
server's static public DH key g^s. The latter signature by the server i=
s
performed only when a new static DH key is created (how often this hap=
pens and
how many such keys are created is completely up to the server -=
 it has the
advantage that these keys can be changed often to increase s=
ecurity against
leaked keys). This use of RSA also enjoys the high effic=
iency of RSA
verification for the client.=C2=A0 
The handling of Clie=
nt certificates would be similar.

Note on forward security (a.k.a. a=
s PFS for Perfect Forward Security): 
PFS is provided by the (mandatory)=
 use of ephemeral Diffie-Hellman keys.
The meaning of PFS is that an att=
acker that finds the (long-term) static
private keys of the parties cann=
ot compromise past session keys. Without the
ServerFinished message the =
above protocol ensures forward secrecy against
passive attackers (i.e., =
for sessions where the attacker did not choose g^y).
With ServerFinished=
, PFS holds also against active attackers.=C2=A0 A similar
consideration=
 applies to ClientFinished.

Client certificates in the first message=
: We note that in cases where client
certificates can be sent in the cle=
ar in the first message of the protocol, one
can provide PFS and mutual =
authentication in a 1-RTT at essentially the same
cost of an unauthentic=
ated DH exchange (i.e., a cost of little more than two
exponentiations).=
 In such a setting one can also obtain mutual authentication in
a 0-RTT =
protocol (with forward secrecy with respect to the client's key).=C2=A0=
 
These options, however, require HMQV-like mechanisms and may raise IP =
issues (this
can be investigated further if the WG is interested).


_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--f46d044280cae413f60506c24319--


From nobody Fri Oct 31 18:59:52 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD951A878B for ; Fri, 31 Oct 2014 18:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.023
X-Spam-Level: 
X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3hI5V6B17mI for ; Fri, 31 Oct 2014 18:59:47 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2681A878A for ; Fri, 31 Oct 2014 18:59:46 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id q5so2609735wiv.17 for ; Fri, 31 Oct 2014 18:59:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kSqvo5Sl7RF31v5Q8V6lwHBLsqg4ePM6k3kQ1LcCpOg=; b=P9pPDaTJRrMt3QTO9PTTSO5miCVCkJ+kV41GF0jxoFJMxZzQ2U+hXbeMlOQeSx1saW D8jyH797KsVUIwxZTI6hvRjR2MrTiNMtNB1eabodzbYJe471Vef5ftNH3iQgXjFC08OE I7qhqMUGohHi24N+FUfA+Xq7PC7rC7QRM+LvP2e1KcFo9Pm0ONjgQuhhA4zx/6YctZQH 3QvPQISrxFN6lHR5bOzHh0jobkhyfHVipu8w+G+fMyTum7JdJNryCxNwidTBGaqSUCg2 FDS0xXk18afPwwwAQAVs6b/BSCKG6b2e8q+1dJ4unGd5td8703Cs+gw/8E0ZA60Z9hBP aLgw==
X-Gm-Message-State: ALoCoQnHRksfsaxBCvsKVElJnS3Gq9UUh3hVZU43gNEk2anLZqzodqLmNjpny5ebyojBjXf2XvQy
X-Received: by 10.180.108.43 with SMTP id hh11mr929699wib.80.1414807185704; Fri, 31 Oct 2014 18:59:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Fri, 31 Oct 2014 18:59:05 -0700 (PDT)
In-Reply-To: 
References:  
From: Eric Rescorla 
Date: Fri, 31 Oct 2014 18:59:05 -0700
Message-ID: 
To: Hugo Krawczyk 
Content-Type: multipart/alternative; boundary=089e0122950abad95b0506c277e6
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tAePl4Pw_W5ogseSmLgJvzXR2io
Cc: "tls@ietf.org" , Hoeteck Wee 
Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Nov 2014 01:59:51 -0000

--089e0122950abad95b0506c277e6
Content-Type: text/plain; charset=UTF-8

P.S. At first glance this kind of design seems to have some really nice
properties and wouldn't be too hard to modify the draft (and
implementations)
to support. I'm looking forward to hearing what the WG thinks.

Best,
-Ekr

On Fri, Oct 31, 2014 at 6:44 PM, Eric Rescorla  wrote:

> Hugo,
>
> Thanks for writing this up. I'm still digesting this, but I had a few
> questions.
>
> 1. In the interim, I believe you suggested MAC of the transcript under
> g^{xs} to authenticate g^y. This is fairly analogous to CertificateVerify,
> except using a MAC rather than a signature. In the current design, you
> instead generate a combined key from g^{xs] and g^{xy}. Are there
> advantages to this design or is it just a matter of style?
>
> 2. I'm thinking about how to adapt this to PSK+PFS modes (i.e.,
> where you want the PSK for authentication but you want to do
> a DHE exchange for PFS). In the design you propose, it seems
> like the analogous thing to do would be to treat the PSK like
> g^{xy}? Does this interact at all with whether to mix the keys
> or use a MAC?
>
> 3. WRT client auth, I think we've generally decided that the client's
> certificate ought to be encrypted. Given that, I wonder if it would be
> easier
> for the client to just do a digital signature over the transcript and/or
> an authenticator derived from the secret. Generally, the additional
> cost of the RSA signature isn't a huge problem for most clients and
> those which do should be able to quickly move to EC-based keys.
>
> Thanks,
> -Ekr
>
>
> On Fri, Oct 31, 2014 at 5:54 PM, Hugo Krawczyk 
> wrote:
>
>> During the TLS interim meeting of last week (Oct 22 2014) I suggested
>> that TLS
>> 1.3 should abandon signature-based authentication (other than for
>> certificates)
>> and be based solely on a combination of ephemeral Diffie-Hellman for PFS
>> and
>> static Diffie-Hellman for authentication. This has multiple benefits
>> including
>> major performance gain (by replacing the per-handshake RSA signature by
>> the
>> server with a much cheaper elliptic curve exponentiation), compatibility
>> with
>> the mechanisms required for forward secrecy, natural accommodation of a
>> 0-RTT
>> option, and a simple extension without signatures for client
>> authentication.
>>
>> Below I present a schematic representation of the proposed protocol
>> referred
>> to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three.
>> The presentation is sketchy and omits the exact procedure for key
>> derivation.
>> The latter is a crucial component for the security of the protocol, but
>> before getting into these details we want to get a sense of whether the
>> WG is
>> interested in this approach. In the meantime, Hoeteck Wee and myself are
>> working on the details of the protocol and the security proof.
>>
>> We describe a setting with optional 0-RTT and server-only authentication.
>> Client authentication can be added as a further option or as an extension
>> (similar to the current 1.3 proposal) - see below.
>>
>> NOTATION AND TERMINOLOGY:
>>
>> [K] symbols represent pointers to key material whose exact derivation is
>> not
>> included here except for specifying the basic DH values from which the
>> key is
>> derived (actual derivation will include further information similar to the
>> extended hash mechanisms or SessionHash proposal considered for 1.3).
>> Asterisks represent optional fields that the WG can decide to leave as
>> optional,
>> mandatory, or simply remove without changing the core cryptographic
>> security of
>> the protocol. All references to encryption mean "authenticated encryption"
>> using the encrypt-then-mac paradigm (or any other secure AEAD
>> mechanism).
>>
>> KeyShare's represent ephemeral Diffie-Hellman values exchanged by the
>> parties.
>> All the public key and Diffie-Hellman operations are assumed to happen
>> over a
>> cyclic group with generator g of order q (typically implemented by an
>> elliptic
>> curve group). We use multiplicative notation where ^ denotes
>> exponentiation as
>> in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y),
>> etc.
>> Omitted from the current high level description is a mechanism for
>> testing group
>> membership of DH values or cofactor exponentiation (the specific mechanism
>> depends on the group type and is typically very efficient for elliptic
>> curves).
>>
>> SERVER PUBLIC KEY AND CERTIFICATE:
>>
>> The server has a long term private-public key pair denoted by (s,g^s)
>> where
>> s is uniform random in [0..q-1] (we refer to s and g^s as "static keys").
>> We assume that the server has a certificate that includes the server's
>> public
>> key g^s and a CA-signed binding of this key to the server's identity.
>> We discuss the implementation of such certificates below.
>>
>> PROTOCOL OPTLS:
>>
>> ClientHello
>> ClientKeyShare
>> ClientData* [K0]       -------->
>>                                            ServerHello
>>                                            ServerKeyShare
>>                                            ServerCertificate* [K1]
>>                                            ServerFinished [K2]
>>                        <--------           ServerData* [K2]
>> ClientFinished* [K2]   -------->
>>
>>
>>             Protected Application Data [K3]
>>                        <------->
>>
>>
>>
>> 1-RTT CASE:
>>
>> The basic 1-RTT case omits the ClientData* field. It includes a
>> ClientKeyShare
>> g^x and a ServerKeyShare g^y and an optional (encrypted) server
>> certificate.
>> If the certificate is sent (it can be omitted if the client has indicated
>> that
>> it knows the server key as in the case in the 0-RTT scenario) and is
>> encrypted,
>> the encryption key K1 is derived from g^{xy}.
>>
>> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is
>> used to
>> authenticate-encrypt the ServerFinished and ClientFinished messages (which
>> include a hash of the previous traffic) and to encrypt data from the
>> server if
>> such data is piggybacked to the second message.
>>
>> Key K3 is the "application key" used to derive key material for
>> protection of
>> application data.  This key material will include (directional)
>> Authenticated
>> Encryption keys and, possibly, keys for derivation of further re-key
>> material.
>> K3 is computed from  both g^{xs} and g^{xy} similarly to K2, but its
>> derivation
>> will be different than K2, e.g., using a separating key expansion
>> technique.
>>
>> SUPPORT FOR 0-RTT:
>>
>> The above protocol is compatible with a 0-RTT protocol such as QUIC. In
>> this
>> case, the client is assumed to have information about the server's public
>> key
>> and other security parameters. The server is assumed to have some
>> mechanism in
>> place for detecting replay (e.g., via timestamps, stored client nonces,
>> etc.).
>> The resulting protocol is as described above where the ClientData field
>> is sent
>> encrypted under key K0 derived from g^{xs}.
>> The rest of the protocol is identical to the above.
>> Note: In this case, ServerCertificate is not sent as the client had to
>> know
>> the server's public key before the first message (one can imagine a
>> setting
>> where the server may send a different certificate in the second message -
>> if
>> desired, this can be accommodated too as an option or extension).
>>
>> CLIENT AUTHENTICATION:
>>
>> Client authentication can be supported via an option or extension. It
>> would
>> include a client certificate for a static DH key g^c sent in the third
>> message
>> (the certificate can be encrypted under key K2 to provide client's
>> identity
>> protection). In this case, the key for computing the ClientFinished
>> message and
>> the application key K3 would be derived from a combination of the values
>> g^xy,
>> g^xs, g^yc (and possibly also g^{cs}).
>>
>> NOTES:
>>
>> Note on Finished messages: The above spec sets ServerFinished as
>> mandatory and
>> ClientFinished as optional. The latter option is needed for a 1-RTT
>> protocol.
>> In principle, both Finished messages could be omitted and still obtain
>> security
>> via implicit authentication (assuming the inputs to key derivation are
>> chosen
>> appropriately). But given the advantages of ServerFinished for providing
>> explicit authentication, key confirmation, and active forward secrecy (see
>> below), it seems advisable to always include it. Including ClientFinished
>> provides key confirmation from client and also explicit client
>> authentication
>> when client certificate is included. ClientFinished also provides
>> Universal
>> Composable (UC) security (this is a result of the Canetti-Krawczyk proof
>> that
>> CK security implies UC security when a client confirmation step is
>> included).
>>
>> Note on certificates: Since in current practice servers hold certificates
>> for
>> RSA signature keys rather than for static DH keys, the certificate field
>> in the
>> above protocol will be implemented by a pair consisting of (i) the
>> server's RSA
>> signature certificate and (ii) the server's signature using this RSA key
>> on the
>> server's static public DH key g^s. The latter signature by the server is
>> performed only when a new static DH key is created (how often this
>> happens and
>> how many such keys are created is completely up to the server - it has the
>> advantage that these keys can be changed often to increase security
>> against
>> leaked keys). This use of RSA also enjoys the high efficiency of RSA
>> verification for the client.
>> The handling of Client certificates would be similar.
>>
>> Note on forward security (a.k.a. as PFS for Perfect Forward Security):
>> PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys.
>> The meaning of PFS is that an attacker that finds the (long-term) static
>> private keys of the parties cannot compromise past session keys. Without
>> the
>> ServerFinished message the above protocol ensures forward secrecy against
>> passive attackers (i.e., for sessions where the attacker did not choose
>> g^y).
>> With ServerFinished, PFS holds also against active attackers.  A similar
>> consideration applies to ClientFinished.
>>
>> Client certificates in the first message: We note that in cases where
>> client
>> certificates can be sent in the clear in the first message of the
>> protocol, one
>> can provide PFS and mutual authentication in a 1-RTT at essentially the
>> same
>> cost of an unauthenticated DH exchange (i.e., a cost of little more than
>> two
>> exponentiations). In such a setting one can also obtain mutual
>> authentication in
>> a 0-RTT protocol (with forward secrecy with respect to the client's
>> key).
>> These options, however, require HMQV-like mechanisms and may raise IP
>> issues (this
>> can be investigated further if the WG is interested).
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>

--089e0122950abad95b0506c277e6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


P.S. At first glance this kind =
of design seems to have some really nice
pr=
operties and wouldn't be too hard to modify the draft (and implementati=
ons)
to support. I'm looking forward to=
 hearing what the WG thinks.

Best,
-Ekr

On Fri, Oct 31, 2014 at 6:44 PM, Eric Rescorla <ekr@rtfm.com>=
; wrote:
Hugo,
Thanks for writing this up. I'm still digesting this, =
but I had a few
questions.

1. In the int=
erim, I believe you suggested MAC of the transcript under
g^{xs} =
to authenticate g^y. This is fairly analogous to CertificateVerify,
except using a MAC rather than a signature. In the current design, you
instead generate a combined key from g^{xs] and g^{xy}. Are there<=
/div>
advantages to this design or is it just a matter of style?
<=
div>
2. I'm thinking about how to adapt this to PSK+=
PFS modes (i.e.,
where you want the PSK for authentication but yo=
u want to do
a DHE exchange for PFS). In the design you propose, =
it seems
like the analogous thing to do would be to treat the PSK=
 like
g^{xy}? Does this interact at all with whether to mix the k=
eys
or use a MAC?
=C2=A0=C2=A0
3. WRT c=
lient auth, I think we've generally decided that the client's
certificate ought to be encrypted. Given that, I wonder if it woul=
d be easier
for the client to just do a digital signature over th=
e transcript and/or
an authenticator derived from the secret. Gen=
erally, the additional
cost of the RSA signature isn't a huge=
 problem for most clients and
those which do should be able to qu=
ickly move to EC-based keys.

Thanks,
-Ek=
r


On Fri, Oct 31, 2014 at 5:54 PM, Hugo Krawczyk <=
span dir=3D"ltr"><hugo@ee.technion.ac.il> wrote:
During the TLS interim meeting of last =
week (Oct 22 2014) I suggested that TLS
1.3 should abandon signature-bas=
ed authentication (other than for certificates)
and be based solely on a=
 combination of ephemeral Diffie-Hellman for PFS and
static Diffie-Hellm=
an for authentication. This has multiple benefits including
major perfor=
mance gain (by replacing the per-handshake RSA signature by the
server w=
ith a much cheaper elliptic curve exponentiation), compatibility with
th=
e mechanisms required for forward secrecy, natural accommodation of a 0-RTT=

option, and a simple extension without signatures for client authentica=
tion.

Below I present a schematic representation of the proposed pro=
tocol referred
to as OPTLS where OPT stands for OPTimized and/or for One=
-Point-Three.=C2=A0 
The presentation is sketchy and omits the exact pro=
cedure for key derivation.
The latter is a crucial component for the sec=
urity of the protocol, but 
before getting into these details we want to=
 get a sense of whether the WG is
interested in this approach. In the me=
antime, Hoeteck Wee and myself are 
working on the details of the protoc=
ol and the security proof.

We describe a setting with optional 0-RTT=
 and server-only authentication.
Client authentication can be added as a=
 further option or as an extension
(similar to the current 1.3 proposal)=
 - see below.

NOTATION AND TERMINOLOGY:

[K] symbols represent=
 pointers to key material whose exact derivation is not
included here ex=
cept for specifying the basic DH values from which the key is
derived (a=
ctual derivation will include further information similar to the
extende=
d hash mechanisms or SessionHash proposal considered for 1.3). 
Asterisk=
s represent optional fields that the WG can decide to leave as optional,mandatory, or simply remove without changing the core cryptographic securi=
ty of
the protocol. All references to encryption mean "authenticate=
d encryption"
using the encrypt-then-mac paradigm (or any other sec=
ure AEAD mechanism).=C2=A0 

KeyShare's represent ephemeral Diffi=
e-Hellman values exchanged by the parties.
All the public key and Diffie=
-Hellman operations are assumed to happen over a
cyclic group with gener=
ator g of order q (typically implemented by an elliptic
curve group). We=
 use multiplicative notation where ^ denotes exponentiation as
in g^x, g=
^{xy} (here xy denotes multiplication of the scalars x and y), etc.
Omit=
ted from the current high level description is a mechanism for testing grou=
p
membership of DH values or cofactor exponentiation (the specific mecha=
nism
depends on the group type and is typically very efficient for ellip=
tic curves).

SERVER PUBLIC KEY AND CERTIFICATE:

The server ha=
s a long term private-public key pair denoted by (s,g^s) where 
s is uni=
form random in [0..q-1] (we refer to s and g^s as "static keys").=
 
We assume that the server has a certificate that includes the server&#=
39;s public
key g^s and a CA-signed binding of this key to the server=
9;s identity.
We discuss the implementation of such certificates below.<=
br>
PROTOCOL OPTLS:

ClientHello
ClientKeyShare 
ClientData*=
 [K0]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -------->
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 ServerHello=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Serve=
rKeyShare=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerCertificate* [K1]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerFinished [K2]
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <--------=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerData* [K2]
ClientFinished* [K=
2]=C2=A0=C2=A0 -------->


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Protected Application Data [K3]
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <------->


1-RTT CASE:

The basic 1-RTT case omits the ClientData* field. I=
t includes a ClientKeyShare
g^x and a ServerKeyShare g^y and an optional=
 (encrypted) server certificate. 
If the certificate is sent (it can be =
omitted if the client has indicated that
it knows the server key as in t=
he case in the 0-RTT scenario) and is encrypted,
the encryption key K1 i=
s derived from g^{xy}.

Key K2 is an encryption key derived from both=
 g^{xs} and g^{xy}. It is used to
authenticate-encrypt the ServerFinishe=
d and ClientFinished messages (which
include a hash of the previous traf=
fic) and to encrypt data from the server if
such data is piggybacked to =
the second message.

Key K3 is the "application key" used t=
o derive key material for protection of
application data.=C2=A0 This key=
 material will include (directional) Authenticated
Encryption keys and, =
possibly, keys for derivation of further re-key material.
K3 is computed=
 from=C2=A0 both g^{xs} and g^{xy} similarly to K2, but its derivation
w=
ill be different than K2, e.g., using a separating key expansion technique.=


SUPPORT FOR 0-RTT: 

The above protocol is compatible with a =
0-RTT protocol such as QUIC. In this
case, the client is assumed to have=
 information about the server's public key
and other security parame=
ters. The server is assumed to have some mechanism in
place for detectin=
g replay (e.g., via timestamps, stored client nonces, etc.).
The resulti=
ng protocol is as described above where the ClientData field is sent
enc=
rypted under key K0 derived from g^{xs}.=C2=A0 
The rest of the protocol=
 is identical to the above.=C2=A0 
Note: In this case, ServerCertificate=
 is not sent as the client had to know
the server's public key befor=
e the first message (one can imagine a setting
where the server may send=
 a different certificate in the second message - if
desired, this can be=
 accommodated too as an option or extension).

CLIENT AUTHENTICATION:=
 

Client authentication can be supported via an option or extension.=
 It would
include a client certificate for a static DH key g^c sent in t=
he third message 
(the certificate can be encrypted under key K2 to prov=
ide client's identity
protection). In this case, the key for computi=
ng the ClientFinished message and
the application key K3 would be derive=
d from a combination of the values g^xy,
g^xs, g^yc (and possibly also g=
^{cs}). 

NOTES:

Note on Finished messages: The above spec set=
s ServerFinished as mandatory and
ClientFinished as optional. The latter=
 option is needed for a 1-RTT protocol.
In principle, both Finished mess=
ages could be omitted and still obtain security
via implicit authenticat=
ion (assuming the inputs to key derivation are chosen
appropriately). Bu=
t given the advantages of ServerFinished for providing
explicit authenti=
cation, key confirmation, and active forward secrecy (see
below), it see=
ms advisable to always include it. Including ClientFinished
provides key=
 confirmation from client and also explicit client authentication
when c=
lient certificate is included. ClientFinished also provides Universal
Co=
mposable (UC) security (this is a result of the Canetti-Krawczyk proof that=
 
CK security implies UC security when a client confirmation step is inc=
luded).=C2=A0 

Note on certificates: Since in current practice serve=
rs hold certificates for
RSA signature keys rather than for static DH ke=
ys, the certificate field in the
above protocol will be implemented by a=
 pair consisting of (i) the server's RSA
signature certificate and (=
ii) the server's signature using this RSA key on the
server's st=
atic public DH key g^s. The latter signature by the server is
performed =
only when a new static DH key is created (how often this happens and
how=
 many such keys are created is completely up to the server - it has the
=
advantage that these keys can be changed often to increase security against=

leaked keys). This use of RSA also enjoys the high efficiency of RSAverification for the client.=C2=A0 
The handling of Client certificates=
 would be similar.

Note on forward security (a.k.a. as PFS for Perfe=
ct Forward Security): 
PFS is provided by the (mandatory) use of ephemer=
al Diffie-Hellman keys.
The meaning of PFS is that an attacker that find=
s the (long-term) static
private keys of the parties cannot compromise p=
ast session keys. Without the
ServerFinished message the above protocol =
ensures forward secrecy against
passive attackers (i.e., for sessions wh=
ere the attacker did not choose g^y).
With ServerFinished, PFS holds als=
o against active attackers.=C2=A0 A similar
consideration applies to Cli=
entFinished.

Client certificates in the first message: We note that =
in cases where client
certificates can be sent in the clear in the first=
 message of the protocol, one
can provide PFS and mutual authentication =
in a 1-RTT at essentially the same
cost of an unauthenticated DH exchang=
e (i.e., a cost of little more than two
exponentiations). In such a sett=
ing one can also obtain mutual authentication in
a 0-RTT protocol (with =
forward secrecy with respect to the client's key).=C2=A0 
These opti=
ons, however, require HMQV-like mechanisms and may raise IP issues (thiscan be investigated further if the WG is interested).



_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls








--089e0122950abad95b0506c277e6--


From nobody Fri Oct 31 21:55:27 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483DD1A87DF for ; Fri, 31 Oct 2014 21:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GniMN1vQ5oSk for ; Fri, 31 Oct 2014 21:55:24 -0700 (PDT)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212781A87DE for ; Fri, 31 Oct 2014 21:55:23 -0700 (PDT)
Received: by mail-wg0-f46.google.com with SMTP id x13so9134324wgg.5 for ; Fri, 31 Oct 2014 21:55:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hQdTb2bMbyOYw2m0vzbz9Js6sK7d/ow9wWLCVzBSfx4=; b=siLBUAn7eJcHz8cOi8PFH1FfZK4nEzETva1YyB2SpAYcuj99/UM56GtpaQTnOaDqyG D15vazQuREyXnfelz+sceI/zy82UypelBfAU6l2lvdpxcKq0uFTLPWD1pF0N+0pwYy5Q N5OR/6XQ7wdI3Y7cWfcb6l0eJIFzcpDcxeRWEQFIxkMaSMmQOXA2ON8B2F5xD5ONhKhN KbX6F56TBjCrGezhmtT7Ze81RZmW/+Ovd7r+rU91iqVyEeU/673f4nvEh8sJaRcj6T7h qu93ToMBdLzzpG2YMVB+zQpHG6GKI+zFkPpvonb7QgvUwQPb4HRSsNBBQhxGOPlJhkOz HKqg==
X-Received: by 10.194.175.67 with SMTP id by3mr32241731wjc.32.1414817722787; Fri, 31 Oct 2014 21:55:22 -0700 (PDT)
Received: from [192.168.1.104] (IGLD-84-228-87-161.inter.net.il. [84.228.87.161]) by mx.google.com with ESMTPSA id hi8sm3019635wjc.34.2014.10.31.21.55.20 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 21:55:22 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir 
In-Reply-To: 
Date: Sat, 1 Nov 2014 06:55:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp>     <98C3E3E6-5BB1-49E0-BF5F-D5378E3D8688@gmail.com> 
To: noloader@gmail.com
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OX8jRNamXCHGxxswlarG-7NxLdQ
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Nov 2014 04:55:26 -0000

> On Nov 1, 2014, at 1:47 AM, Jeffrey Walton  wrote:
>=20
> On Fri, Oct 31, 2014 at 12:04 PM, Yoav Nir  =
wrote:
>>=20
>> On Oct 31, 2014, at 7:55 PM, Yuhong Bao  =
wrote:
>>=20
>> SSLv2 had much worse security flaws than SSLv3 did.
>>=20
>>=20
>> Other than the downgrade attack by a MITM, what else?
>>=20
>=20
> "Differences Between SSLv2, SSLv3, and TLS",
> http://yaksman.org/~lweith/ssl.pdf. There's three or four pages of
> problems enumerated by Weith.

Not using compression. As a security flaw.=20

The truncation issue could be a real one, but a lot os HTTPS servers =
closed all sessions without an alert, so the truncation was possible =
with SSLv3 as well.

The padding and sake-key issues are real issues. Thanks.

It its defence, SSLv2 did not have the insecure renegotiation thing, =
which has caused more heartburn to more people than any cleartext pad =
length.

Yoav


From nobody Fri Oct 31 22:15:45 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48061A87E7 for ; Fri, 31 Oct 2014 22:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.099
X-Spam-Level: *
X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-9y45iliMUR for ; Fri, 31 Oct 2014 22:15:39 -0700 (PDT)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA341A87D7 for ; Fri, 31 Oct 2014 22:15:39 -0700 (PDT)
Received: by mail-yk0-f180.google.com with SMTP id 9so3816755ykp.25 for ; Fri, 31 Oct 2014 22:15:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WS6NyFSihJLD1+7ZCAHDaOCflguRP5ZIe022xgsPHiE=; b=jJAvfidqVg+ce0RYTkjjSfKIIj9kBfufWoUDVBFzFXXyL/7DxpXmUdiN0wsRFdXDRM 9Df/nE7o8+U0LugHODtoTOJcVv73w9Cnb991nRdBvGCWR2jAXFQaMz7jhEEGbP2I0nRf sB2zn3gOWltHPWM8iigGgGl+JE+/xEKda366Bb5W7bWoZ/jG7FC3asgqaXSTcatzWULY nK+++UB8hAbtoMHzLGzkH3LoMImR7I/d0GbDBYuYvBrhcaJnYL+1c/5O2MBahrr5ci8L B5xELGZal6nrf7M5+T7SgpeLwET+7XOWevs3iAgWz/nSJwztQY/EdLENA91N/MJ9hJup 7rhg==
MIME-Version: 1.0
X-Received: by 10.236.208.71 with SMTP id p47mr314498yho.5.1414818938566; Fri, 31 Oct 2014 22:15:38 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Fri, 31 Oct 2014 22:15:38 -0700 (PDT)
In-Reply-To: 
References:   
Date: Fri, 31 Oct 2014 22:15:38 -0700
Message-ID: 
From: Watson Ladd 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yugtDpXxxZat0QK_khxn0WlwDyM
Cc: Hoeteck Wee , "tls@ietf.org" 
Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Nov 2014 05:15:43 -0000

Dear Hugo,

There are some issues I can see:

-Servers already supporting ECDSA certificates seem to not win. If I'm
understanding correctly, a server does three exponentiations, one of
which can be optimized by ephemeral reuse, when using ECDSA+ECDHE. The
servers that win are the ones with RSA certs. The only way to win vs
ECDSA is if DH only permits faster exponentiation, which it does, and
removing the ancillary junk in ECDSA.  However, here we have two
variable base exponentiations after ephemeral reuse, as opposed to one
fixed, one variable, so there is a loss in performance on the same
group, made up for by removing inversions modulo the group order.

-I'm interested to see how different this is from ntor.[0] (To my eyes
it is very similar, which may make proving easier. OTOH, the 0-RTT and
1-RTT options require care). Similarly, Michael Backes and coauthors
have proposed Ace[1], which does similar tricks to HMQV to reduce
server side cost, and provides a key exchange with some similar
properties.

-Estimations of the cost of group computations require care: while
those in the original email are correct, the estimates for shared-base
and multibase have to take into account the existence of ladders. A
seeming optimization might force the use of a slower representation.
In genus 1 this is no longer an issue.

-We've already had controversy on the list about removing
renegotiation as a mechanism for client authentication. While I would
really like to see a symmetric client authentication method, the fact
that some people want to change the client authentication state in the
middle of the connection limits the kinds of options we have. (I don't
know what exactly the requirements are or how they limit the options,
but I remember this being raised in an earlier proposal for removing
renegotiation)

None of these issues look like showstoppers to me. I think the
benefits of this proposal, particularly with regards to 0-RTT and
1-RTT exchanges where there is a solid proposal as opposed to none at
all, significantly outweigh the minor disadvantages. It opens the door
to massive performance increases by removing a dependency on signing,
and the consequent annoyances. And lastly, it will hopefully have a
proof that is understandable by humans with reasonable assumptions.

Sincerely,
Watson Ladd
-----


[0] http://cacr.uwaterloo.ca/techreports/2011/cacr2011-11.pdf
[1] https://www.infsec.cs.uni-saarland.de/~mohammadi/paper/owake.pdf

On Fri, Oct 31, 2014 at 6:59 PM, Eric Rescorla  wrote:
> P.S. At first glance this kind of design seems to have some really nice
> properties and wouldn't be too hard to modify the draft (and
> implementations)
> to support. I'm looking forward to hearing what the WG thinks.
>
> Best,
> -Ekr
>
> On Fri, Oct 31, 2014 at 6:44 PM, Eric Rescorla  wrote:
>>
>> Hugo,
>>
>> Thanks for writing this up. I'm still digesting this, but I had a few
>> questions.
>>
>> 1. In the interim, I believe you suggested MAC of the transcript under
>> g^{xs} to authenticate g^y. This is fairly analogous to CertificateVerify,
>> except using a MAC rather than a signature. In the current design, you
>> instead generate a combined key from g^{xs] and g^{xy}. Are there
>> advantages to this design or is it just a matter of style?
>>
>> 2. I'm thinking about how to adapt this to PSK+PFS modes (i.e.,
>> where you want the PSK for authentication but you want to do
>> a DHE exchange for PFS). In the design you propose, it seems
>> like the analogous thing to do would be to treat the PSK like
>> g^{xy}? Does this interact at all with whether to mix the keys
>> or use a MAC?
>>
>> 3. WRT client auth, I think we've generally decided that the client's
>> certificate ought to be encrypted. Given that, I wonder if it would be
>> easier
>> for the client to just do a digital signature over the transcript and/or
>> an authenticator derived from the secret. Generally, the additional
>> cost of the RSA signature isn't a huge problem for most clients and
>> those which do should be able to quickly move to EC-based keys.
>>
>> Thanks,
>> -Ekr
>>
>>
>> On Fri, Oct 31, 2014 at 5:54 PM, Hugo Krawczyk 
>> wrote:
>>>
>>> During the TLS interim meeting of last week (Oct 22 2014) I suggested
>>> that TLS
>>> 1.3 should abandon signature-based authentication (other than for
>>> certificates)
>>> and be based solely on a combination of ephemeral Diffie-Hellman for PFS
>>> and
>>> static Diffie-Hellman for authentication. This has multiple benefits
>>> including
>>> major performance gain (by replacing the per-handshake RSA signature by
>>> the
>>> server with a much cheaper elliptic curve exponentiation), compatibility
>>> with
>>> the mechanisms required for forward secrecy, natural accommodation of a
>>> 0-RTT
>>> option, and a simple extension without signatures for client
>>> authentication.
>>>
>>> Below I present a schematic representation of the proposed protocol
>>> referred
>>> to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three.
>>> The presentation is sketchy and omits the exact procedure for key
>>> derivation.
>>> The latter is a crucial component for the security of the protocol, but
>>> before getting into these details we want to get a sense of whether the
>>> WG is
>>> interested in this approach. In the meantime, Hoeteck Wee and myself are
>>> working on the details of the protocol and the security proof.
>>>
>>> We describe a setting with optional 0-RTT and server-only authentication.
>>> Client authentication can be added as a further option or as an extension
>>> (similar to the current 1.3 proposal) - see below.
>>>
>>> NOTATION AND TERMINOLOGY:
>>>
>>> [K] symbols represent pointers to key material whose exact derivation is
>>> not
>>> included here except for specifying the basic DH values from which the
>>> key is
>>> derived (actual derivation will include further information similar to
>>> the
>>> extended hash mechanisms or SessionHash proposal considered for 1.3).
>>> Asterisks represent optional fields that the WG can decide to leave as
>>> optional,
>>> mandatory, or simply remove without changing the core cryptographic
>>> security of
>>> the protocol. All references to encryption mean "authenticated
>>> encryption"
>>> using the encrypt-then-mac paradigm (or any other secure AEAD mechanism).
>>>
>>> KeyShare's represent ephemeral Diffie-Hellman values exchanged by the
>>> parties.
>>> All the public key and Diffie-Hellman operations are assumed to happen
>>> over a
>>> cyclic group with generator g of order q (typically implemented by an
>>> elliptic
>>> curve group). We use multiplicative notation where ^ denotes
>>> exponentiation as
>>> in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y),
>>> etc.
>>> Omitted from the current high level description is a mechanism for
>>> testing group
>>> membership of DH values or cofactor exponentiation (the specific
>>> mechanism
>>> depends on the group type and is typically very efficient for elliptic
>>> curves).
>>>
>>> SERVER PUBLIC KEY AND CERTIFICATE:
>>>
>>> The server has a long term private-public key pair denoted by (s,g^s)
>>> where
>>> s is uniform random in [0..q-1] (we refer to s and g^s as "static keys").
>>> We assume that the server has a certificate that includes the server's
>>> public
>>> key g^s and a CA-signed binding of this key to the server's identity.
>>> We discuss the implementation of such certificates below.
>>>
>>> PROTOCOL OPTLS:
>>>
>>> ClientHello
>>> ClientKeyShare
>>> ClientData* [K0]       -------->
>>>                                            ServerHello
>>>                                            ServerKeyShare
>>>                                            ServerCertificate* [K1]
>>>                                            ServerFinished [K2]
>>>                        <--------           ServerData* [K2]
>>> ClientFinished* [K2]   -------->
>>>
>>>
>>>             Protected Application Data [K3]
>>>                        <------->
>>>
>>>
>>>
>>> 1-RTT CASE:
>>>
>>> The basic 1-RTT case omits the ClientData* field. It includes a
>>> ClientKeyShare
>>> g^x and a ServerKeyShare g^y and an optional (encrypted) server
>>> certificate.
>>> If the certificate is sent (it can be omitted if the client has indicated
>>> that
>>> it knows the server key as in the case in the 0-RTT scenario) and is
>>> encrypted,
>>> the encryption key K1 is derived from g^{xy}.
>>>
>>> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is
>>> used to
>>> authenticate-encrypt the ServerFinished and ClientFinished messages
>>> (which
>>> include a hash of the previous traffic) and to encrypt data from the
>>> server if
>>> such data is piggybacked to the second message.
>>>
>>> Key K3 is the "application key" used to derive key material for
>>> protection of
>>> application data.  This key material will include (directional)
>>> Authenticated
>>> Encryption keys and, possibly, keys for derivation of further re-key
>>> material.
>>> K3 is computed from  both g^{xs} and g^{xy} similarly to K2, but its
>>> derivation
>>> will be different than K2, e.g., using a separating key expansion
>>> technique.
>>>
>>> SUPPORT FOR 0-RTT:
>>>
>>> The above protocol is compatible with a 0-RTT protocol such as QUIC. In
>>> this
>>> case, the client is assumed to have information about the server's public
>>> key
>>> and other security parameters. The server is assumed to have some
>>> mechanism in
>>> place for detecting replay (e.g., via timestamps, stored client nonces,
>>> etc.).
>>> The resulting protocol is as described above where the ClientData field
>>> is sent
>>> encrypted under key K0 derived from g^{xs}.
>>> The rest of the protocol is identical to the above.
>>> Note: In this case, ServerCertificate is not sent as the client had to
>>> know
>>> the server's public key before the first message (one can imagine a
>>> setting
>>> where the server may send a different certificate in the second message -
>>> if
>>> desired, this can be accommodated too as an option or extension).
>>>
>>> CLIENT AUTHENTICATION:
>>>
>>> Client authentication can be supported via an option or extension. It
>>> would
>>> include a client certificate for a static DH key g^c sent in the third
>>> message
>>> (the certificate can be encrypted under key K2 to provide client's
>>> identity
>>> protection). In this case, the key for computing the ClientFinished
>>> message and
>>> the application key K3 would be derived from a combination of the values
>>> g^xy,
>>> g^xs, g^yc (and possibly also g^{cs}).
>>>
>>> NOTES:
>>>
>>> Note on Finished messages: The above spec sets ServerFinished as
>>> mandatory and
>>> ClientFinished as optional. The latter option is needed for a 1-RTT
>>> protocol.
>>> In principle, both Finished messages could be omitted and still obtain
>>> security
>>> via implicit authentication (assuming the inputs to key derivation are
>>> chosen
>>> appropriately). But given the advantages of ServerFinished for providing
>>> explicit authentication, key confirmation, and active forward secrecy
>>> (see
>>> below), it seems advisable to always include it. Including ClientFinished
>>> provides key confirmation from client and also explicit client
>>> authentication
>>> when client certificate is included. ClientFinished also provides
>>> Universal
>>> Composable (UC) security (this is a result of the Canetti-Krawczyk proof
>>> that
>>> CK security implies UC security when a client confirmation step is
>>> included).
>>>
>>> Note on certificates: Since in current practice servers hold certificates
>>> for
>>> RSA signature keys rather than for static DH keys, the certificate field
>>> in the
>>> above protocol will be implemented by a pair consisting of (i) the
>>> server's RSA
>>> signature certificate and (ii) the server's signature using this RSA key
>>> on the
>>> server's static public DH key g^s. The latter signature by the server is
>>> performed only when a new static DH key is created (how often this
>>> happens and
>>> how many such keys are created is completely up to the server - it has
>>> the
>>> advantage that these keys can be changed often to increase security
>>> against
>>> leaked keys). This use of RSA also enjoys the high efficiency of RSA
>>> verification for the client.
>>> The handling of Client certificates would be similar.
>>>
>>> Note on forward security (a.k.a. as PFS for Perfect Forward Security):
>>> PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys.
>>> The meaning of PFS is that an attacker that finds the (long-term) static
>>> private keys of the parties cannot compromise past session keys. Without
>>> the
>>> ServerFinished message the above protocol ensures forward secrecy against
>>> passive attackers (i.e., for sessions where the attacker did not choose
>>> g^y).
>>> With ServerFinished, PFS holds also against active attackers.  A similar
>>> consideration applies to ClientFinished.
>>>
>>> Client certificates in the first message: We note that in cases where
>>> client
>>> certificates can be sent in the clear in the first message of the
>>> protocol, one
>>> can provide PFS and mutual authentication in a 1-RTT at essentially the
>>> same
>>> cost of an unauthenticated DH exchange (i.e., a cost of little more than
>>> two
>>> exponentiations). In such a setting one can also obtain mutual
>>> authentication in
>>> a 0-RTT protocol (with forward secrecy with respect to the client's key).
>>> These options, however, require HMQV-like mechanisms and may raise IP
>>> issues (this
>>> can be investigated further if the WG is interested).
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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