Re: [TLS] Should CCM_8 CSs be Recommended?

[Eric Rescorla]

I think this text is good. I suggest "Not Recommended" with a note, and if
the IoT groups want to publish their own document updating that note, that
would work.

-Ekr



On Mon, Oct 9, 2017 at 4:05 PM, Sean Turner  wrote:

> Anybody else has thoughts on this?
>
> spt
>
> > On Oct 3, 2017, at 18:53, Sean Turner  wrote:
> >
> > In the IANA registries draft (https://github.com/tlswg/
> draft-ietf-tls-iana-registry-updates), we’ve added a recommended column
> to the Cipher Suites (CSs) registry (and some others).  Right now, the
> criteria for getting a recommended mark is AEAD ciphers with strong
> authentication standards track ciphers.  While that’s great generally, the
> list we’ve got five CSs that gave Joe and I pause:
> >
> > TLS_DHE_RSA_WITH_AES_128_CCM_8
> > TLS_DHE_RSA_WITH_AES_256_CCM_8
> > TLS_PSK_DHE_WITH_AES_128_CCM_8
> > TLS_PSK_DHE_WITH_AES_256_CCM_8
> > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256
> >
> > The CCM_8 CSs have a significantly truncated authentication tag that
> represents a security trade-off that may not be appropriate for general
> environment.  In other words, this might be great for some IoT device but
> we should not generally be recommending these.
> >
> > We’re recommending that these five suites be dropped from the
> recommended list.  Please let us know what you think.
> >
> > J
> > (editor hats on)
>
> ___
> 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] Should CCM_8 CSs be Recommended?

[Sean Turner]

Anybody else has thoughts on this?

spt

> On Oct 3, 2017, at 18:53, Sean Turner  wrote:
> 
> In the IANA registries draft 
> (https://github.com/tlswg/draft-ietf-tls-iana-registry-updates), we’ve added 
> a recommended column to the Cipher Suites (CSs) registry (and some others).  
> Right now, the criteria for getting a recommended mark is AEAD ciphers with 
> strong authentication standards track ciphers.  While that’s great generally, 
> the list we’ve got five CSs that gave Joe and I pause:
> 
> TLS_DHE_RSA_WITH_AES_128_CCM_8
> TLS_DHE_RSA_WITH_AES_256_CCM_8
> TLS_PSK_DHE_WITH_AES_128_CCM_8
> TLS_PSK_DHE_WITH_AES_256_CCM_8
> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256
> 
> The CCM_8 CSs have a significantly truncated authentication tag that 
> represents a security trade-off that may not be appropriate for general 
> environment.  In other words, this might be great for some IoT device but we 
> should not generally be recommending these.
> 
> We’re recommending that these five suites be dropped from the recommended 
> list.  Please let us know what you think.
> 
> J
> (editor hats on)

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

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

[Nick Sullivan]

Ralph and Russ,

This draft addresses the two main concerns I had with draft-green:
1) Client opt-in
2) On-the wire visibility

There are clearly some details missing from this draft (such as how Ke is
used as a symmetric key), but generally I think this approach is more
explicit and therefore less likely to unintentionally impact the broader
internet if used in the datacenter setting.

Nick

On Mon, Oct 2, 2017 at 1:31 PM Ralph Droms  wrote:

> We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS
> extension defined in this I-D takes into account what we heard from the
> discussion regarding TLS visibility and
> draft-green-tls-static-dh-in-tls13-00 in Prague. Specifically, it provides
> an opt-in capability for both the TLS client and server and makes it clear
> on the wire that visibility will be enabled for the session.  The new
> mechanism does not depend on static handshake or session keys.
>
> - Ralph and Russ
>
>
> ___
> 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] Update on TLS 1.3 Middlebox Issues

[Ilari Liusvaara]

On Mon, Oct 09, 2017 at 07:21:01PM +0200, Martin Rex wrote:
> Ilari Liusvaara  wrote:
> >
> > And even if the changes might not be directly consequential to
> > security, the changes to get through some more annoying middleboxes
> > might be quite annoying to implement.
> > 
> > E.g. there probably are several different middeboxes that have a
> > configuration that actually checks that the handshake looks valid,
> > which includes checks for things like ChangeCipherSpec being
> > present in both directions, even for resumption; while the non-
> > resumption mode might even verify the authentication signatures in
> > the handshake and not letting server send non-handshake messages
> > before sending its 2nd flight. Ugh, getting around those would be
> > pretty nasty.
> 
> 
> Fixing the backwards-incompatibilities in the TLS record layer
> would be terribly useful for streaming-optimized IO layers as well,
> i.e. ensure the the TLS record properly identifies ContentType,
> and that a TLSv1.3 handshake ends with CCS followed by 1 Handshake message.

Unfortunately, doing that would do really bad things to security.

And the middleboxes I am talking about actually parse every cleartext
handshake message. Change anything in any message and they fail. And
fixing some known vulnerabilities in TLS 1.2 is not possible without
changing the structures around.

In fact, I think the record layer changes in TLS 1.3 actually _reduce_
intolerance, not _increase_ it. If your middlebox is not as anal as I
described above, it probably falls into copying data back and forth
when it loses the handshake. However, the changes into ServerHello
could easily cause trouble even with such middleboxes.


Here what might work getting around those really annoying middleboxes
(and this is pretty nasty):

- Add back the session field, echo field from client
- Add dummy zero into place of compression method, so TLS 1.2 parsers
  can parse the message.
- Fix ServerVersion at TLS 1.2, send true version in supported_versions
  extension.
- If the version is TLS 1.3, the session id is non-empty and 0-RTT was
  not accepted, insert fake ChangeCipherSpec message immediately after
  ServerHello and change outer content-type of the next record to 22
  (instead of 23). The client can do the same.

This might be able to make the middlebox think that first part of
the handshake is actually TLS 1.2 stateful session resumption. But as
said, blech at the hack. Hmm... Ciphersuites could cause problems
still.


With less annoying middleboxes, the following would also work:

- Add two zeros into ServerHello so the message can be parsed the same
  way as TLS 1.2.


And with slightly more annoying than that:

- Add two zeros into ServerHello so the message can be parsed the same
  way as TLS 1.2.
- Fix ServerVersion at TLS 1.2, send true version in supported_versions
  extension.




-Ilari

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

Re: [TLS] draft-rhrd (Was: Re: Update on TLS 1.3 Middlebox Issues)

[Stephen Farrell]

I did a bit of an update to [1].

As before PRs are welcome and I (still) wonder if the
WG would benefit from documenting bits of this stuff
as a work item to save time and repetition in future.

S.

[1] https://github.com/sftcd/tinfoil

On 08/10/17 23:35, Blumenthal, Uri - 0553 - MITLL wrote:
> +1 to Stephen.
> 
> Regards,
> Uri
> 
> Sent from my iPhone
> 
>> On Oct 8, 2017, at 18:34, Stephen Farrell  wrote:
>>
>>
>>
>>> On 08/10/17 23:22, Eric Rescorla wrote:
>>> You seem to be responding to some other thread. 
>>
>> Yep. I changed the subject line.
>>
>> Randy's substantive message however is crystal clear. And is
>> one that WG participants ought take to heart IMO. Pretending
>> that some changes to TLS would magically be limited in scope
>> to so-called "data centres" is BS. I'm really really puzzled
>> that some otherwise sensible folks appear unable to see that.
>>
>> S
>>
>>
>>> As both Adam Langley and I
>>> mentioned, none of the changes that anyone is investigating for reducing
>>> middlebox-induced breakage affect the cryptographic properties of TLS.
>>>
>>> -Ekr
>>>
>>>
 On Sun, Oct 8, 2017 at 2:42 PM, Randy Bush  wrote:

 there are a lot of us lurkers out here a bit horrified watching this wg
 go off the rails.

 it would help if vendors of devices which break privacy would stop
 speaking for 'datacenters' and let datacenters speak for themselves.  i
 have not seen any doing so.  my $dayjob has >10 medium sized datacenters
 serving everything from banks to telcos to scaled cloud services.  i can
 not find folk in our datacenter groups who see a need to break e2e
 encryption.

 if the interception proposals ensured that user is notified and able to
 prevent session interception, then i would believe this.  but if they do
 not, then let's face it, this is all about selling surveillance gear to
 snooping enterprises and repressive regiemes where people with guns take
 you away at 3am because your session was decoded.

 can we please provide real end to end privacy or call this wg something
 else?

 randy

 ___
 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
>>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Update on TLS 1.3 Middlebox Issues

[Martin Rex]

Ilari Liusvaara  wrote:
>
> And even if the changes might not be directly consequential to
> security, the changes to get through some more annoying middleboxes
> might be quite annoying to implement.
> 
> E.g. there probably are several different middeboxes that have a
> configuration that actually checks that the handshake looks valid,
> which includes checks for things like ChangeCipherSpec being
> present in both directions, even for resumption; while the non-
> resumption mode might even verify the authentication signatures in
> the handshake and not letting server send non-handshake messages
> before sending its 2nd flight. Ugh, getting around those would be
> pretty nasty.


Fixing the backwards-incompatibilities in the TLS record layer
would be terribly useful for streaming-optimized IO layers as well,
i.e. ensure the the TLS record properly identifies ContentType,
and that a TLSv1.3 handshake ends with CCS followed by 1 Handshake message.

-Martin

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

Re: [TLS] Update on TLS 1.3 Middlebox Issues

[Martin Rex]

Eric Rescorla  wrote:
>
> two options:
> 
> - Try to make small adaptations to TLS 1.3 to make it work better with
> middleboxes.

Return to the proper TLSv1.2 record format with true ContentTypes
(hiding them doesn't add any security anyways).

With the needlessly broken ContentTypes, we will be unable to support
TLSv1.3 in our current apps.

The needless changes break streaming of layered IO and end-of-communication
discovery for long-running requests, because it is not possible to
reliably distinguish a warning-level closure alert from a pipelined
continuation of app data.


-Martin

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