Re: [TLS] Data volume limits

[Nikos Mavrogiannopoulos]

On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote:

> Therefore, I think we shouldn't add the rekeying mechanism as it is
> unnecessary and it adds too much complexity. 

Any arbitrary limit for a TLS connection is almost guaranteed to cause
problems in the future. We cannot predict whether 2^x should be
sufficient for everyone, and I'm pretty sure this will prove to be a
terrible mistake. TLS is already being used for VPNs and transferring
larger amounts of data in long lived connections is a reality even
today. The rekey today happens using the reauthentication mechanism,
which has very complex semantics. Converting these to a simpler and
predictable rekey mechanism would be an improvement.

regards,
Nikos


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

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-cached-info-20: (with COMMENT)

[Stephen Farrell]

On 17/12/15 14:58, Kathleen Moriarty wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-tls-cached-info-20: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Just a quick comment, sorry for asking this late and I won't hold up on
> it either, just want to raise the question without quite enough time to
> research it all.
> 
> I see the SHA-256 truncation is just 32 bits.  In other applications,
> about half is what is typically recommended.  I know you are trying to
> cut on space, but will problems arise from this shorter value?

Nah, I think this one's ok. IIUC, the result of a collision is
just a handshake fail, and then presumably recovery when they
ditch the cached stuff. Section 5 describes this.

S.


> 
> 

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

Re: [TLS] Explicit use of client and server random values

[Hugo Krawczyk]

I have mentioned this in private conversations but let me say this here: I
would prefer that the nonces be explicitly concatenated to the handshake
hash.  That is,

handshake_hash = Hash(

client random||

server random||

Hash(handshake_messages) ||

Hash(configuration) || )


The reason is that nonces are essential for freshness and session
uniqueness and I want to see them explicitly included in the
signed/mac-ed/KDF-ed information. I can envision a future variant/mode of
the protocol where parties do not transmit nonces but have a synchronized
state that they advance separately and use as nonces (e.g., for key
refreshing) - in such case the nonces would not be included in the
handshake-hash computation.

So while the redundancy of having them twice in the handshake_hash
calculation may be annoying, this adds robustness to the security (and
analysis) of the protocol.

Another reason for including them (in particular as the leading values) in
the computation of handshake_hash is to have them always located at the
same position in the hashed stream. It is needed to make sure that these
streams are unique per session (in theory, and maybe in practice, an
attacker may play games changing the boundary of nonces by changing
surrounding bytes in the stream).

If this augmenting of handshake_hash is not adopted then there should be a
note cautioning against excluding the nonces from the transmitted messages.
If possible, it would be good to move them to a fixed position (from the
start of the input to the handshake_hash).

Hugo

On Thu, Dec 17, 2015 at 10:13 AM, John Foley  wrote:

> On 12/16/2015 04:28 PM, Dave Garrett wrote:
>
>> On Wednesday, December 16, 2015 04:15:00 pm John Foley wrote:
>>
>>> Thanks for answering my questions.  Have you considered adding KAT
>>> values for the key derivation steps?  This would be helpful to
>>> implementors.  RFC5869 already has KAT values for HKDF-Extract and
>>> HKDF-Expand.  But the TLS 1.3 spec has added HKDF-Expland-Label.
>>> Additionally, It would be useful to show intermediate KAT values for
>>> xSS, xES, mSS, and mES.
>>>
>> I suggest filing an issue or submitting a PR with a starting point set of
>> changes and discussing it with ekr.
>>
>>
> I've submitted https://github.com/tlswg/tls13-spec/issues/378.  If you
> give me a few days, I'll update this issue with KAT values per revision
> 10.  Since it sounds like there are changes forthcoming in this section of
> the draft, I'll hold off on the PR until later. Hopefully someone else will
> volunteer to verify my KAT values.
>
>
> ___
> 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] Explicit use of client and server random values

[Eric Rescorla]

On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk 
wrote:

> I have mentioned this in private conversations but let me say this here: I
> would prefer that the nonces be explicitly concatenated to the handshake
> hash.  That is,
>
> handshake_hash = Hash(
>
> client random||
>
> server random||
>
> Hash(handshake_messages) ||
>
> Hash(configuration) || )
>
>
> The reason is that nonces are essential for freshness and session
> uniqueness and I want to see them explicitly included in the
> signed/mac-ed/KDF-ed information. I can envision a future variant/mode of
> the protocol where parties do not transmit nonces but have a synchronized
> state that they advance separately and use as nonces (e.g., for key
> refreshing) - in such case the nonces would not be included in the
> handshake-hash computation.
>
> So while the redundancy of having them twice in the handshake_hash
> calculation may be annoying, this adds robustness to the security (and
> analysis) of the protocol.
>

This change doesn't make implementation or specification significantly more
difficult.
Does anyone  else object or feel it makes analysis harder? :)

-Ekr



Another reason for including them (in particular as the leading values) in
> the computation of handshake_hash is to have them always located at the
> same position in the hashed stream. It is needed to make sure that these
> streams are unique per session (in theory, and maybe in practice, an
> attacker may play games changing the boundary of nonces by changing
> surrounding bytes in the stream).
>
> If this augmenting of handshake_hash is not adopted then there should be a
> note cautioning against excluding the nonces from the transmitted messages.
> If possible, it would be good to move them to a fixed position (from the
> start of the input to the handshake_hash).
>
> Hugo
>
> On Thu, Dec 17, 2015 at 10:13 AM, John Foley  wrote:
>
>> On 12/16/2015 04:28 PM, Dave Garrett wrote:
>>
>>> On Wednesday, December 16, 2015 04:15:00 pm John Foley wrote:
>>>
 Thanks for answering my questions.  Have you considered adding KAT
 values for the key derivation steps?  This would be helpful to
 implementors.  RFC5869 already has KAT values for HKDF-Extract and
 HKDF-Expand.  But the TLS 1.3 spec has added HKDF-Expland-Label.
 Additionally, It would be useful to show intermediate KAT values for
 xSS, xES, mSS, and mES.

>>> I suggest filing an issue or submitting a PR with a starting point set
>>> of changes and discussing it with ekr.
>>>
>>>
>> I've submitted https://github.com/tlswg/tls13-spec/issues/378.  If you
>> give me a few days, I'll update this issue with KAT values per revision
>> 10.  Since it sounds like there are changes forthcoming in this section of
>> the draft, I'll hold off on the PR until later. Hopefully someone else will
>> volunteer to verify my KAT values.
>>
>>
>> ___
>> 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

[TLS] Poly1305 vs GCM

[James Cloos]

Given the issues w/ gcm currently under discussion, and that poly1305
was originally proposed to use w/ aes, should tls recommend aes-poly1305
instead of aes-gcm for those who want to continue to use aes?

Or does chacha-poly1305 not fall victim to the 2^36 attack not because
of the aead but rather because of chacha?

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6


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

Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379)

[Cedric Fournet]

As explained below, we propose that the record-layer sequence numbers
be reset to 0 whenever new keys are installed (as in TLS 1.2):

https://github.com/tlswg/tls13-spec/pull/379

Cédric Fournet, on behalf of the miTLS team.


While working on a formal model of the TLS 1.3 record layer, I bumped
into a new weakness due to the chaining of sequence numbers between
epochs.

In the current draft, the sequence number is not reset when a new key
is installed. This is a new mechanism we suggested a while ago: the
intent was to prevent suffix truncations of traffic encrypted with the
old key by making the first decryption with the new key fail.

This mechanism prevents suffix truncations when *both* keys are
secure, but it introduces a new weakness when the old key is
compromised and the new key is secure.  Then, the attacker gains the
ability to delete the first few fragments encrypted with the new key,
which we think is not acceptable.

This is problematic when switching from the 0RTT keys to the handshake
keys, then to the application keys, as the whole point of the TLS 1.3
key schedule is to gradually establish stronger keys. We discuss below
some of the complications it may cause.

PREFIX TRUNCATION: HANDSHAKE ---> APPLICATION

This weakness in the transition from the handshake key to the
application data key may be exploited as follows:

* The client and server complete a 1-RTT handshake, and some
  implementation bug causes the handshake key to be leaked.

* The attacker may play with handshake message fragmentation to
  artificially increase the sequence number on either side of the
  channel. The handshake data remains untouched, so the handshake can
  still be successful. 

* When the client and server start exchanging application data (using
  the new, secure key), the attacker can remove as many fragments as
  he added to truncate application data in both directions!

PREFIX TRUNCATION: 0RTT ---> HANDSHAKE 

A variant may also occurs during the change from the 0-RTT key to the
handshake key:

* The client first sends 0RTT-encrypted fragments, then
  handshake-encrypted fragments.

* The attacker breaks the 0RTT key, and rewrites 0RTT traffic to
  insert additional fragments, for instance by fragmenting the 0RTT
  payload into several fragments. For each additional fragment with
  the old key, it also deletes a fragment encrypted with the new key,
  and then forwards the rest of the client traffic unchanged.

* The server's sequence number is higher than the client's when it
  changes key, but nonetheless the server successfully decrypt all
  received fragments.

Similarly, if the server refuses 0RTT but continues the handshake, it
is unclear which sequence number the client should use for encrypting
handshake traffic. If the client continues with the 0RTT sequence
number, then the only way for the server to decrypt the handshake
traffic is to count how many 0RTT fragments it discards---and this can
be controlled by the attacker, even without breaking the 0RTT key!

Although prefix truncations will probably cause the handshake to fail,
this complicates the analysis of the record layer, whose security now
depends on the details of the handshake protocol. There are also
corner cases; for instance, assuming alerts are protected using the
current keys (as they are in TLS 1.2), it may be possible to silently
delete a warning from the client to the server, or to truncate half of
the client certificate and observe whether the second half starts with
a well-formed alert fragment.

OUR PROPOSAL. In the current draft, the ends of encrypted traffic have
now all be made explicit (using end_of_early_data; Finished; and
close_notify), so there is no apparent need to chain sequence numbers.

We propose to revert this change (that is, to reset the sequence
number each time a new key is installed, as in TLS 1.2). If the
chaining is still required for some other reason, one could instead
include the old sequence number in the new key derivation (or the new
key's additional data, but we believe this is no longer an option).

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

Re: [TLS] Poly1305 vs GCM

[Ilari Liusvaara]

On Thu, Dec 17, 2015 at 02:14:18PM -0500, James Cloos wrote:
> Given the issues w/ gcm currently under discussion, and that poly1305
> was originally proposed to use w/ aes, should tls recommend aes-poly1305
> instead of aes-gcm for those who want to continue to use aes?
> 
> Or does chacha-poly1305 not fall victim to the 2^36 attack not because
> of the aead but rather because of chacha?

AFAIK, there are two possible reasons for the difference (one or both
may contribute):

- Chacha20 is PRF(unction), AES is PRP(ermutation).
- Chacha20-Poly1305 has per-packet r and s, AES-Poly1305 and AES-GCM
  only has per-packet s and per-key r (as originally proposed).


-Ilari

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

Re: [TLS] Explicit use of client and server random values

[Mike Hamburg]

> On Dec 17, 2015, at 12:11 PM, Eric Rescorla  wrote:
> 
> 
> 
> On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk  > wrote:
> I have mentioned this in private conversations but let me say this here: I 
> would prefer that the nonces be explicitly concatenated to the handshake 
> hash.  That is, 
> 
> handshake_hash = Hash(
> client random||
> server random||
> Hash(handshake_messages) ||
> Hash(configuration)  ||
>)
> 
> The reason is that nonces are essential for freshness and session uniqueness 
> and I want to see them explicitly included in the signed/mac-ed/KDF-ed 
> information. I can envision a future variant/mode of the protocol where 
> parties do not transmit nonces but have a synchronized state that they 
> advance separately and use as nonces (e.g., for key refreshing) - in such 
> case the nonces would not be included in the handshake-hash computation.
> 
> So while the redundancy of having them twice in the handshake_hash 
> calculation may be annoying, this adds robustness to the security (and 
> analysis) of the protocol.
>  
> This change doesn't make implementation or specification significantly more 
> difficult.
> Does anyone  else object or feel it makes analysis harder? :)
> 
> -Ekr

While I haven’t been following TLS 1.3 development all that closely, I will 
question this request.

TLS is annoying to implement and analyze in part because it hashes more-or-less 
arbitrary parts of the handshake messages together, in arbitrary order, at 
arbitrary times.  Removal of all the explicit hashing of client/server random 
in TLS 1.3 makes it clearer what’s going on, and makes implementations simpler. 
 Some of the crypto operations still feel pretty arbitrary (particularly 
Finished), but things seem to be improving overall.  In this context, it feels 
like adding client random and server random back to the hash is a regression.

From an analysis point of view, the client and server random are parseable from 
Hash(handshake messages) because they are concatenated with framing 
information.  But here, they are concatenated without framing information.  So 
I don’t understand Hugo’s contention that the old scheme leads to trouble if 
the nonce changes sizes in a later version, and that the new scheme does not.  
It seems to me that the reverse is more likely to be true.

Cheers,
— Mike___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Data volume limits

[Yoav Nir]

> On 17 Dec 2015, at 10:19 AM, Nikos Mavrogiannopoulos  wrote:
> 
> On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote:
> 
>> Therefore, I think we shouldn't add the rekeying mechanism as it is
>> unnecessary and it adds too much complexity. 
> 
> Any arbitrary limit for a TLS connection is almost guaranteed to cause
> problems in the future. We cannot predict whether 2^x should be
> sufficient for everyone, and I'm pretty sure this will prove to be a
> terrible mistake. TLS is already being used for VPNs and transferring
> larger amounts of data in long lived connections is a reality even
> today. The rekey today happens using the reauthentication mechanism,
> which has very complex semantics. Converting these to a simpler and
> predictable rekey mechanism would be an improvement.

Agreed. The alternative to having a rekey mechanism is to push the complexity 
to the application protocol, requiring it to be able to use more than one 
connection to transfer all the data, which may require some sort of session 
layer to maintain state between connections.

So unless we can guarantee or require that every algorithm we are going to use 
is good for some ridiculous amount of data (2^64 bytes may be enough), we need 
rekeying.

Yoav

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

Re: [TLS] Explicit use of client and server random values

[Salz, Rich]

> Does anyone  else object or feel it makes analysis harder? :)

Oh yeah, like anyone's gonna disagree with Hugo that this makes the analysis 
harder :)

Paging Watson ... :)

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-cached-info-20: (with COMMENT)

[Kathleen Moriarty]

On Thu, Dec 17, 2015 at 10:09 AM, Stephen Farrell
 wrote:
>
>
> On 17/12/15 14:58, Kathleen Moriarty wrote:
>> Kathleen Moriarty has entered the following ballot position for
>> draft-ietf-tls-cached-info-20: Yes
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> Just a quick comment, sorry for asking this late and I won't hold up on
>> it either, just want to raise the question without quite enough time to
>> research it all.
>>
>> I see the SHA-256 truncation is just 32 bits.  In other applications,
>> about half is what is typically recommended.  I know you are trying to
>> cut on space, but will problems arise from this shorter value?
>
> Nah, I think this one's ok. IIUC, the result of a collision is
> just a handshake fail, and then presumably recovery when they
> ditch the cached stuff. Section 5 describes this.

OK, no hold up on it, there just wasn't an explanation in the draft as
to why 32 bits was enough in section 5 (or any other).

Thanks,
Kathleen

>
> S.
>
>
>>
>>



-- 

Best regards,
Kathleen

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

[TLS] Kathleen Moriarty's Yes on draft-ietf-tls-cached-info-20: (with COMMENT)

[Kathleen Moriarty]

Kathleen Moriarty has entered the following ballot position for
draft-ietf-tls-cached-info-20: Yes

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/



--
COMMENT:
--

Just a quick comment, sorry for asking this late and I won't hold up on
it either, just want to raise the question without quite enough time to
research it all.

I see the SHA-256 truncation is just 32 bits.  In other applications,
about half is what is typically recommended.  I know you are trying to
cut on space, but will problems arise from this shorter value?


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

[TLS] Ben Campbell's No Objection on draft-ietf-tls-cached-info-20: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-tls-cached-info-20: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/



--
COMMENT:
--

-section 4, paragraph 4:
It might be helpful to have a little more guidance to clients for
multi-tenant server environments. For example, the fact that it might
want to cache different certs from the same server in the first place.
Also, when might it be reasonable to violate the RECOMMENDED?

- 4.1:
Should the reference for 7250 be normative?


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