Re: [TLS] TLS@IETF101 Agenda Posted

[Peter Bowen]

On Tue, Mar 13, 2018 at 3:16 PM, Russ Housley  wrote:
> Second, using
> TLS1.2 does not technically address the issue.  If the client were to
> exclusively offer DHE-based ciphersuites, then the visibility techniques
> that have been used in the past are thwarted.

I expect this configuration to become more common in the future.  In
November 2017, US NIST published draft SP 800-52 r2
(https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft )
which explicitly disallows all non-DH cipher suites.  The comment
period closed on 1 Feb 2018, and none of the published comments pushed
back on this.  Given that PCI DSS and many other standards refer to
the NIST Special Publications for implementation requirements, I would
not be surprised to see DH-only (including ECDH/ECDHE/DHE) become
prevalent.

Based on the comments from the proponents of the various drafts, it
would seem that this should be a bigger concern than any changes in
TLS 1.3, as it is implementable today.  I highly suspect that the
currently deployed systems will not handle handshakes that only offer
DH suites, right?

Thanks,
Peter

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Peter Bowen]

On Wed, Oct 25, 2017 at 3:40 PM, Stephen Farrell
 wrote:
>
>
> On 25/10/17 23:37, Richard Barnes wrote:
>> Sorry, what?  The current draft proposes an extension, literally the
>> opposite of a standard, supported feature.  It's explicitly optional.
>
> Optional is not the opposite of standard.
>
> See the intended status below.
>
>> I don't really have a dog in this fight, but let's please be accurate.
>
> Accuracy level is just fine I think.

So, to be completely clear, no one is arguing that Nick's three
options (quoted below) are wrong or do not work.  The objection is
that the IETF should not be publishing a RFC that documents them, is
that right?

Nick Sullivan wrote:
> 1) use TLS 1.2 with RSA -> one single key
> 2) use TLS 1.3 with DH key derived from seed -> one single key (similar to 
> draft-green)
> 3) use any version of TLS and export the session keys -> corpus of keys equal 
> to number of connections

Thanks,
Peter

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

Re: [TLS] Industry Concerns about TLS 1.3

[Peter Bowen]

On Fri, Sep 23, 2016 at 2:10 PM, BITS Security
 wrote:
>  we need a better option than TLS 1.2 that will, perhaps sooner than we might 
> expect, be deprecated.

I'm somewhat confused here.  The concern over RSA for key exchange
versus DH for key exchange would only seem to apply when the network
tapping system has access to the RSA key, right?  So the part of this
about monitoring the network for external chat and such doesn't really
change if the client is using TLS 1.1 or 1.3, as you still can't
decrypt the connection just from monitoring, right?

If that is true, then it implies that the server is at least somewhat
under control of the monitor, so it can support TLS 1.2 as long as
needed.  TLS 1.0 came out in 1999 and is still now (in 2016) widely
deployed.  While I hope TLS 1.3 deployment is speedy, I don't forsee
browsers dropping TLS 1.2 and earlier support any time soon.

Thanks,
Peter

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

Re: [TLS] AD review of draft-ietf-tls-falsestart-01

[Peter Bowen]

On Thu, Mar 31, 2016 at 6:19 PM, Sean Turner  wrote:
>
> 0) As described above: Get it approved by the IESG, hold it in RFC editor’s 
> queue, and publish it as historic at the same time TLS 1.3 is published.

I'm not a fan of this option simply because
draft-ietf-tls-negotiated-ff-dhe has been stuck is MISSREF state in
the RFC editor queue for months waiting on this draft.  I don't think
there is any question the ffdhe draft is forward looking and I, for
one, would like to see it published before TLS 1.3.

Thanks,
Peter

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

Re: [TLS] 回复： A TLS extension transfering service indication information

[Peter Bowen]

It doesn't seem to be clearly spelled out: is the "charging GW" a
system that can read data passing between the client and server but
cannot modify it?  If so, do I have it right that you are trying to
design an extension that allows the client to send a message that can
be observed but not tampered?

On Tue, Mar 29, 2016 at 9:12 PM, Dacheng Zhang
 wrote:
> The charging GW will not authenticate the client, it only needs to be
> informed how the following traffics will be charged, in a trusted way.
> That is why we will do this work. For secure reasons, we intend to use TLS
> to secure the traffics to or from our APP. So, we need to provide such
> information in some way to the charging GW of ISP.
>
> 在 16-3-30 下午12:06， "Martin Thomson"  写入:
>
>>On 30 March 2016 at 15:04, Dacheng Zhang 
>>wrote:
>>> Dacheng：Let assume we trust the device. But the APP use a SNI to
>>>indicate
>>> the service that the APP intends to access. Because the SNI is static
>>>which
>>> may not be changed for months, it is easier for attackers who monitor
>>>the
>>> network to get the SNI and use it to gain benefit. We need a securer
>>> solution. As I have mentioned in my previous email, this solution will
>>>make
>>> such attacks more difficult. By the way, SNI is not designed for this
>>> purpose, we need to do some additional work to address this issue,
>>>right?
>>
>>
>>What is wrong with client authentication?
>
>
> ___
> 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

Re: [TLS] Fixing TLS

[Peter Bowen]

On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen <pzbo...@gmail.com> wrote:
> On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett <davemgarr...@gmail.com> wrote:
>> On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
>>> Martin's comment reminded me of the following that I've been meaning to
>>> post...
>>>
>>> In a recent discussion among some crypto folks, the topic of what TLS 1.3
>>> could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path 
>>> from
>>> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The 
>>> discussion
>>> centered around the fact that we already have lots of analysis done for TLS
>>> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
>>> problems while being as compatible as possible with existing infrastructure.
>>> So what this would do is take existing security analysis applied to TLS,
>> [...]
>>
>> Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have snacks.
>>
>> I'll be the bearer of bad news and tell you that your proposal has come up 
>> in multiple forms. I suggested a similar thing a while back and far before 
>> me others have as well. The chairs have, however, long declared consensus 
>> that we want to focus on a single new version not leaving out other more 
>> complex changes, namely latency improvements.
>
> Rather than talking about this as TLS 1.2.1 (or 1.3), is the smarter
> way to go to document a profile of TLS 1.2 that covers almost all of
> this.  From a quick read, existing RFCs and I-Ds cover most of this:
> - RFC 5246 (TLS 1.2 & TLS_DHE_RSA_WITH_AES_128_CBC_SHA256)
> - RFC 5487 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA256)
> - RFC 5289 (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256)
> - RFC 7366 (EtM)
> - RFC 7627 (extended master secret)
> - RF 4055 (RSA-PSS)
>
> The gaps seem to be:
> - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
> (BoringSSL has an implementation using cipher suite 0xca,0xfe)

Correction: draft-mattsson-tls-ecdhe-psk-aead-03 defines this suite.
Still no cipher suite allocated, but there is an active draft.

> - DH parameters -- the alternative would be using FFDH named groups
> (draft-ietf-tls-negotiated-ff-dhe-10), right?
>
> This would only leave "Get rid of the IPsec cargo-cult MAC truncation", right?
>
> Thanks,
> Peter

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

Re: [TLS] Fixing TLS

[Peter Bowen]

On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett  wrote:
> On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
>> Martin's comment reminded me of the following that I've been meaning to
>> post...
>>
>> In a recent discussion among some crypto folks, the topic of what TLS 1.3
>> could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path 
>> from
>> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The discussion
>> centered around the fact that we already have lots of analysis done for TLS
>> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
>> problems while being as compatible as possible with existing infrastructure.
>> So what this would do is take existing security analysis applied to TLS,
> [...]
>
> Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have snacks.
>
> I'll be the bearer of bad news and tell you that your proposal has come up in 
> multiple forms. I suggested a similar thing a while back and far before me 
> others have as well. The chairs have, however, long declared consensus that 
> we want to focus on a single new version not leaving out other more complex 
> changes, namely latency improvements.

Rather than talking about this as TLS 1.2.1 (or 1.3), is the smarter
way to go to document a profile of TLS 1.2 that covers almost all of
this.  From a quick read, existing RFCs and I-Ds cover most of this:
- RFC 5246 (TLS 1.2 & TLS_DHE_RSA_WITH_AES_128_CBC_SHA256)
- RFC 5487 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA256)
- RFC 5289 (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256)
- RFC 7366 (EtM)
- RFC 7627 (extended master secret)
- RF 4055 (RSA-PSS)

The gaps seem to be:
- No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
(BoringSSL has an implementation using cipher suite 0xca,0xfe)
- DH parameters -- the alternative would be using FFDH named groups
(draft-ietf-tls-negotiated-ff-dhe-10), right?

This would only leave "Get rid of the IPsec cargo-cult MAC truncation", right?

Thanks,
Peter

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