Re: [TLS] (strict) decoding of legacy_record_version?

[Martin Thomson]

On 9 November 2016 at 05:59, Brian Smith  wrote:
> This isn't a pervasively shared goal, though. It's good to let the browsers
> police things if they want, but I think a lot of implementations would
> prefer to avoid doing work that isn't necessary for interop or security.

If you permit someone to enforce it, then that is sufficient.  I don't
think that we should ever force someone to enforce these sorts of
things (as you say, sometimes strict enforcement isn't cheap or even
desirable).

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

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

[Martin Thomson]

On 8 November 2016 at 21:08, Daniel Migault  wrote:
> TLS enable curve negotiation but not for code point. This makes restrictions
> on code points hard to implement.  As a result Endpoints MAY treat
> negotiation of key sizes smaller than the lower limits as a connection error
> of type insufficient_security(71) for TLS 1.2 and TLS 1.3.

I really had a hard time parsing this.  You don't connect this to
Diffie-Hellman at all, but I think that is what you are talking about.
But if your point is that this is an ECDHE-specific draft, then you
don't need to say anything at all.

nit "TLS enables"

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

Re: [TLS] COSIC's look on TLS 1.3

[Eric Rescorla]

On Tue, Nov 8, 2016 at 2:33 PM, Ilari Liusvaara 
wrote:

> - Yeah, there have been complaints about lack of state diagram, stating
>   that the present ladder diagram is not sufficient.
>

Yeah, I'm taking this point to heart. I've been a bit swamped with
implementation
matters, but I'll get working on a state machine diagram.

-Ekr


>
>
> -Ilari
>
> ___
> 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] COSIC's look on TLS 1.3

[Ilari Liusvaara]

On Tue, Nov 08, 2016 at 03:55:36PM +0100, Roel Peeters wrote:
> Dear all,
> 
> just to let you know that we have written a blog post on the current TLS
> 1.3 draft, with our remarks that might be of use in your upcoming meeting.
> 
> https://securewww.esat.kuleuven.be/cosic/?p=6624

Some comments:

- I would expect ClientHello to identify the TLS library client uses,
  by fingerprinting ClientHello. E.g. btls has very characteristic
  ClientHello (Elliptic curve 30  and signature 0x0808 are very rare).
- Outside statically provisioned PSKs, the PSK identifiers are supposed
  to be use-once (or at most use few times tightly spaced).
- Speed matters, therefore TLS 1.3 has been designed with the greatest
  speed -> 2 client flights and 1 server flight till data transport
  is fully up. Which is theoretical minimum for any protocol with key
  confirmation.
- Checks have bad tendency of being omitted, so I personally prefer
  more complex key schedule that can force the properies.
- The state machine complexity mostly comes from all the messages in
  the handshake, none really seems removable/mergeable without
  introducing more problems.
- The obfustication is meant for one purpose only: Prventing attackers
  from correlating dynamic PSK connection with its parent. Note that
  masking is additive, so even multiple-use of the same PSK does not
  allow correlation of parent session. The child sessions would be
  correlated, but those are easily correlated by the identifiers
  anyway.
- Yes,the correct way is to invalidate tickets on use. The reason the
  mechanism is done this way is to support stateful and stateless as
  good as possible (obviously, stateless mechanisms have inherit
  problems).
- Regarding 0-RTT data, yes it scares me... If just for the fact that
  it appears to be much more difficult to analyze than just about
  anything else (another scary feature is post-handshake auth, given the
  possiblities for applications to seriously shoot themselves to the
  foot with it, in non-obvious ways).
- Receiving the same PSK twice is only possible within the same
  connection: Because associated PSK master key will be different on
  every connection attempt, and forcing it to be the same would require
  breaking the PRF hash (which already causes severe issues).
- Even if client reuses PSKs, unless the ClientHellos are exactly the
  same (including Random field, which is supposed to be 256 random
  bits), the keys will almost certainly be forced different (if PRF
  hash is strong). This also holds for 0-RTT keys.
- Yeah, there have been complaints about lack of state diagram, stating
  that the present ladder diagram is not sufficient.



-Ilari

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

Re: [TLS] COSIC's look on TLS 1.3

[Dave Garrett]

On Tuesday, November 08, 2016 09:55:36 am Roel Peeters wrote:
> we are also wondering whether or not the Hello Retry Request will be
> included or omitted in the standard. Leaving it out will make TLS 1.3
> vulnerable again to downgrade attacks ...

Why are you wondering about this? HRR is in the specification and there has 
been no discussion to remove it.


Dave

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

Re: [TLS] COSIC's look on TLS 1.3

[Sean Turner]

I let this message through the moderator queue despite the link to the blog; 
next time please send your comments directly to the list.  Note that I wouldn’t 
necessarily expect anybody to pick up your points for you; PRs are welcome 
though.

spt

> On Nov 08, 2016, at 20:25, Roel Peeters  wrote:
> 
> Dear all,
> 
> just to let you know that we have written a blog post on the current TLS
> 1.3 draft, with our remarks that might be of use in your upcoming meeting.
> 
> https://securewww.esat.kuleuven.be/cosic/?p=6624
> 
> Best regards,
> 
> Roel Peeters and Jens Hermans
> 
> PS: we are also wondering whether or not the Hello Retry Request will be
> included or omitted in the standard. Leaving it out will make TLS 1.3
> vulnerable again to downgrade attacks ...
> 
> ___
> 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] COSIC's look on TLS 1.3

[Roel Peeters]

Dear all,

just to let you know that we have written a blog post on the current TLS
1.3 draft, with our remarks that might be of use in your upcoming meeting.

https://securewww.esat.kuleuven.be/cosic/?p=6624

Best regards,

Roel Peeters and Jens Hermans

PS: we are also wondering whether or not the Hello Retry Request will be
included or omitted in the standard. Leaving it out will make TLS 1.3
vulnerable again to downgrade attacks ...

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

Re: [TLS] (strict) decoding of legacy_record_version?

[Brian Smith]

Martin Thomson  wrote:

> On 8 November 2016 at 14:01, Brian Smith  wrote:
> > Since this field isn't included in the additional_data of the AEAD in TLS
> > 1.3 any more, it isn't authenticated. That means an active MitM can use
> this
> > to transport up to 2 bytes of information hop-to-hop if the receiver
> doesn't
> > check it. That seems like a good reason to check it, and also to check
> > TLSCiphertext.opaque_type is application_data. Assuming this is the
> reason,
> > the reasoning should be explicitly called out because it is non-obvious.
>
> I don't think that's the primary reason.  A MitM could use TCP headers
> to carry other bits if they wanted.
>

Smuggling at the application layer would be more reliable for them, though.
I'd say the goal of the check isn't to prevent all possible smuggling;
rather it's part of a solution to it. Anyway, this is the only convincing
rationale I see for requiring ("MUST") vs allowing ("MAY") the checking.



> The main reason I can think of is ecosystem health.  If you permit
> junk, then you get junk.  Then you can't use the field any more
> because it contains junk.
>

This isn't a pervasively shared goal, though. It's good to let the browsers
police things if they want, but I think a lot of implementations would
prefer to avoid doing work that isn't necessary for interop or security.

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Salz, Rich]

> the PDUs are still pretty much predictable
> heuristically (by their ordering), even when they're padded.

...
 
> So besides being completely pointless, can you describe any realistic problem
> that is worth breaking middleware at the endpoints so badly?

I found the language difference interesting.  We could conduct an interesting 
thought experiment by reversing the emphasis on each of the above fragments.  
But I won't.

Instead, I'll point out that this is in-charter, in-scope, and WG consensus has 
generally been to "encrypt all the bits" as much as feasible.

Some applications in some corners of some enterprises, might lose out.

Just like those who depending on static RSA, right?

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Martin Rex]

Yoav Nir wrote:
> 
>> On 3 Nov 2016, at 20:20, Martin Rex  wrote:
>> 
>>> With visible content type, you can tell these two flows apart.
>> 
>> (a) so what?  for those interested, one can tell such flows appart
>> pretty reliably by traffic analysis.  So there is exactly ZERO
>> protection against bad guys, while breaking the good guys.
> 
> There is if you pad the records to the size of application records.

There is no such padding by default.  And the TLS handshake is
half-duplex, and for any interested third party, who performs the
handshake with the server himself for comparison, the PDUs are still
pretty much predictable heuristically (by their ordering), even
when they're padded.

So besides being completely pointless, can you describe any realistic
problem that is worth breaking middleware at the endpoints so badly? 


> 
> > (b) but TLSv1.2 remains unchanged, and this flow does not seem to
> > exist in TLSv1.3, since renegotiation no longer exists in TLSv1.3.
> 
> Re-negoatiation doesn?t, but post-handshake client authentication does:
> https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.5.2 
> 
> 
> > -- so why would we need a backwards-incompatible change in a
> > protocol that protects something that no longer exists,
> > but which severely breaks existing middleware, making it
> > impossible to drop-in replace a TLSv1.2 implementation with
> > a TLSv1.3 implementation that has this backwards-incompatibility.
> 
> Can you elaborate on that middleware?

As previously mentioned, it is middleware that facilitates using
a TLS-protected communication channel for application callers.  It offers
several different kinds of reading strategies to the caller, which the
caller is free to choose from.  One reading mode is "streaming", where
as many app-data TLS records are read (non-blocking) and decrypted,
as fit into the application-supplied buffer.  This facilitates communication
with servers that fragment app data into pathologically small pieces
(e.g. Google).

Non-Appdata records (such as a final Close-Notify or a renegotiation request)
are left in the network buffers, and will only be fully read&processed
after all AppData preceding it have been properly returned to the application.


In a similar fashion, the reverse proxy part (often in the DMZ), can
check whether a browser prematurely aborts a communication and closes
the network connection, by checking for readable events on the network
socket and peeking whether it is a hard connection closure (TCP RESET,
such as MSIE), or a CloseNotify Alert (Firefox,Chrome), without
reading&decoding any application data.


For large-scale Servers, non-blocking network operations are much more
efficient than blocking network operations, the general wait point of
the application is a select/poll call which waits on sockets, and
it is up to the application to decide whether to "select for read" when
it is ready to receive application data on a communication channel.

With appdata records clearly distinguishable at the outer TLS record layer,
the event-based architecture of the application did not need any changes
when switching from cleartext communication to TLS-encrypted communication,
all app-data socket-readable events remained visible with SSLv3->TLSv1.2,
because TLS appdata records can be clearly distinguished from
Handshake, CCS and Alert.

-Martin

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

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

[Daniel Migault]

If I understand correctly, you recommend something that is of the flavor in
the security recommendation section:

TLS enable curve negotiation but not for code point. This makes
restrictions on code points hard to implement.  As a result Endpoints MAY
treat negotiation of key sizes smaller than the lower limits as a
connection error of type insufficient_security(71) for TLS 1.2 and TLS 1.3.

If that is correct I will propose some better text explaining why we can
hardly provide some better text, including the one provided by HTTP2.

Yours,
Daniel


On Tue, Nov 8, 2016 at 4:49 AM, Nikos Mavrogiannopoulos 
wrote:

> On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote:
>
> > Regarding Niko, my understanding is that the WG preferred not to have
> > the definition of profiles in this document. I am not sure you wanted
> > the text to be removed as MUST NOT was to normative or if you would
> > like no recommendation at all. The reason I would rather advocate for
> > recommendation is that ECDHE does not specify an algorithm with a
> > specific security. As a result, I would rather provide some guide
> > lines to avoid weak authentication being used with high long AES
> > keys.
>
> That's a valid concern, but TLS doesn't have the notion of a security
> level, and I am not sure that you can easily introduce it with a
> ciphersuite point assignment rfc. With TLS you can easily use AES-256
> with DHE-RSA with DH parameters of 4096-bits, signed with an RSA
> certificate of 32-bits. One can use your draft with a 8-bit PSK, and
> still be insecure despite the fact that you force a 256-bit curve or
> better. When trying to ensure a consistent level you may likely need to
> adjust the finished message size as well.
>
> Nevertheless, I think to cover your goal, a security considerations
> addition that makes apparent that in addition to the ciphersuite
> parameters, the TLS protocol finished message size, the elliptic curves
> used, and the size of the selected key define the security level of the
> session.
>
> regards,
> Nikos
>
> ___
> 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] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

[Nikos Mavrogiannopoulos]

On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote:

> Regarding Niko, my understanding is that the WG preferred not to have
> the definition of profiles in this document. I am not sure you wanted
> the text to be removed as MUST NOT was to normative or if you would
> like no recommendation at all. The reason I would rather advocate for
> recommendation is that ECDHE does not specify an algorithm with a
> specific security. As a result, I would rather provide some guide
> lines to avoid weak authentication being used with high long AES
> keys.  

That's a valid concern, but TLS doesn't have the notion of a security
level, and I am not sure that you can easily introduce it with a
ciphersuite point assignment rfc. With TLS you can easily use AES-256
with DHE-RSA with DH parameters of 4096-bits, signed with an RSA
certificate of 32-bits. One can use your draft with a 8-bit PSK, and
still be insecure despite the fact that you force a 256-bit curve or
better. When trying to ensure a consistent level you may likely need to
adjust the finished message size as well.

Nevertheless, I think to cover your goal, a security considerations
addition that makes apparent that in addition to the ciphersuite
parameters, the TLS protocol finished message size, the elliptic curves
used, and the size of the selected key define the security level of the
session.

regards,
Nikos

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

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

[Daniel Migault]

Hi Martin, Niko,

Thanks for the comment. Regarding Martin comment, I agree the text should
not comment the SHAX as these are defined by the cipher suites. What is not
clear to me is how the reference to DH should be handled. I also did not
feel that the provided text provides different recommendations for the
AES-128 / AES-256.

This is the text I would propose then. Please let me know if it catches
your comments and feel free to comment on it.

Regarding Niko, my understanding is that the WG preferred not to have the
definition of profiles in this document. I am not sure you wanted the text
to be removed as MUST NOT was to normative or if you would like no
recommendation at all. The reason I would rather advocate for
recommendation is that ECDHE does not specify an algorithm with a specific
security. As a result, I would rather provide some guide lines to avoid
weak authentication being used with high long AES keys.

Yours,
Daniel
-- Text --
When choosing AES-128 cipher suites, servers SHOULD select a key exchange
that is at least 224 bits for cipher suites that use ephemeral elliptic
curve Diffie-Hellman (ECDHE)[RFC4492].

When choosing AES-256 cipher suites, servers SHOULD select a key exchange
that is at least 384 bits for cipher suites that use ephemeral elliptic
curve Diffie-Hellman (ECDHE)[RFC4492].

TLS enable curve negotiation but not for code point.  This makes
restrictions on code points hard to implement.  As a result Endpoints MAY
treat negotiation of key sizes smaller than the lower limits as a
connection error of type insufficient_security(71) for TLS 1.2 and TLS 1.3.

On Tue, Nov 8, 2016 at 3:24 AM, Nikos Mavrogiannopoulos 
wrote:

> On Mon, 2016-11-07 at 22:09 -0500, Daniel Migault wrote:
> > Hi,
> >
> > Please find the text I propose. Let me know if you have any comment
> > regarding the proposed text. Unless I receive comment on it, the text
> > will be publish as soon as draft submission is possible.
> >
> > Yours,
> > Daniel
> >
> >The cipher suites defined in this document are based on the AES-
> > GCM
> >and AES-CCM Authenticated Encryption with Associated Data (AEAD)
> >algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM,
> > and
> >AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and
> >AEAD_AES_256_CCM_8 defined in [RFC6655].
> >
> >For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF)
> >with SHA-256 as the hash function SHALL be used and Clients and
> >Servers MUST NOT negotiate curves of less than 255 bits.
>
> Sorry for not getting back into previous discussions. My comment as
> before would be to remove the text "Clients and Servers MUST NOT
> negotiate curves of less than 255 bits."
>
> I find that unrelated to the purpose of the text which is define code
> points for certain ciphersuites, and no other code points for TLS set
> such restrictions (DH bits, or curves). Alternatively if with this
> document you want to create a profile of TLS (e.g, like SuiteB rfc
> does), which sets options which are more than just ciphersuites then
> just be clear about it.
>
> That is, say this document creates a profile of TLS named XXX which if
> used, the clients and servers which conform to it must negotiate the
> ciphersuites defined above and must not negotiate curves of less than
> 255 bits.
>
> regards,
> Nikos
>
> ___
> 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] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

[Nikos Mavrogiannopoulos]

On Mon, 2016-11-07 at 22:09 -0500, Daniel Migault wrote:
> Hi, 
> 
> Please find the text I propose. Let me know if you have any comment
> regarding the proposed text. Unless I receive comment on it, the text
> will be publish as soon as draft submission is possible.
> 
> Yours, 
> Daniel
> 
>    The cipher suites defined in this document are based on the AES-
> GCM
>    and AES-CCM Authenticated Encryption with Associated Data (AEAD)
>    algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM,
> and
>    AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and
>    AEAD_AES_256_CCM_8 defined in [RFC6655].
> 
>    For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF)
>    with SHA-256 as the hash function SHALL be used and Clients and
>    Servers MUST NOT negotiate curves of less than 255 bits.

Sorry for not getting back into previous discussions. My comment as
before would be to remove the text "Clients and Servers MUST NOT
negotiate curves of less than 255 bits."

I find that unrelated to the purpose of the text which is define code
points for certain ciphersuites, and no other code points for TLS set
such restrictions (DH bits, or curves). Alternatively if with this
document you want to create a profile of TLS (e.g, like SuiteB rfc
does), which sets options which are more than just ciphersuites then
just be clear about it.

That is, say this document creates a profile of TLS named XXX which if
used, the clients and servers which conform to it must negotiate the
ciphersuites defined above and must not negotiate curves of less than
255 bits. 

regards,
Nikos

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