Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

[Martin Thomson]

I'm mainly just looking to economize on different configurations.

On 9 October 2016 at 16:32, John Mattsson  wrote:
> Hi Martin,
>
>
> AES_256_CCM_8 was not in the first versions of the draft but added later
> after request from IoT people (probably afraid of quantum computers).
>
>
> While I think it makes very much sense to have short tags in wireless
> radio, I do not know how large need there is for AES-256 in IoT for
> constrained devices, or how large the need would be to truncate the tag in
> these cases.
>
>
> My current understanding is that Grover’s algorithm may never be more
> cost-effective than a cluster of classical computers, and that quantum
> computers therefore likely do not affect the lifetime of AES-128.
>
>
> I do not have any strong opinions regarding keeping AES_256_CCM_8 or not.
> We should not give the impression that AES-256 is needed for practical
> resistance to quantum computers anytime soon, it is however a requirement
> for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM seems
> like the best choices in most cases.
>
>
> Cheers,
> John
>
>
>
> On 12/08/16 08:29, "TLS on behalf of Martin Thomson"  on behalf of martin.thom...@gmail.com> wrote:
>
>>Looking at those emails, I am prompted to wonder if anyone can justify
>>the existence of a ciphersuite with a double-sized key and half-sized
>>authentication tag.  RFC 6655 doesn't really explain how that is a
>>useful thing.
>>
>>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos 
>>wrote:
>>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote:
 All,

 We've received a request for early IANA assignments for the 6 cipher
 suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh
 e-psk-aead/.  Please respond before August 23rd if you have concerns
 about early code point assignment for these cipher suites.
>>>
>>> I have previously raised an issue [0] on these ciphersuites. The same
>>> requirement was noted also by Peter Dettman as something special in
>>> [1]. However, there has been no reaction from the authors (now in CC).
>>>
>>> regards,
>>> Nikos
>>>
>>> [0].
>>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ
>>> [1].
>>>https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds
>>>
>>> ___
>>> 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

Re: [TLS] Finished stuffing/PSK Binders

[Hugo Krawczyk]

On Fri, Oct 7, 2016 at 1:08 PM, Eric Rescorla  wrote:

>
>
> On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara  > wrote:
>
>> On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote:
>> > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara <
>> ilariliusva...@welho.com>
>> > wrote:
>> >
>> > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
>> > > > 4. I've taken a suggestion from David Benjamin to move the
>> negotiation
>> > > > of the PSK key exchange parameters out of the PSK itself and into a
>> > > > separate message. This cleans things up and also lets us drop the
>> > > > currently non-useful auth_mode parameter.
>> > >
>> > > Eeh... From the text, it seems to currently require the kex modes
>> > > extension if PSK extension is present. Which seems worse than useless
>> > > if the meaning is to get rid of the kex mode parameter from PSK
>> > > extension (since you will have the value anyway, but need to dig it
>> > > from another extension... Blech).
>> >
>> > I guess this is a matter of taste, but what convinced me was that:
>> >
>> > 1. It put all the logic on the server side.
>> > 2. It removed the auth mod parameter.
>> >
>> > Maybe david can say more.
>>
>> I mean if server is to accept PSK, it must now go fishing for another
>> extension, check that it is present and pay attention to values there.
>> As opposed to having the data in where it is needed.
>>
>
> This is a reasonable argument (and the reason I stuffed the binder here).
> However, David's argument was that this applied to *all* PSKs even new
> ones.
>
>
> -Ekr
>
> > > Also, didn't notice what prevents pathology like this (I presume this
>> > > is not allowed):
>> > >
>> > > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256)
>> > >
>> > > ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication]
>> --->
>> > > [0-RTT data, encrypted using AES-128-GCM-SHA256]
>> > > <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256]
>> > > <-- EncryptedExtensions[EarlyDataIndication]
>> > >
>> > > Note the record protection algorithm mismatch.
>> > >
>> >
>> > Yes, this is forbidden by the combination of:
>> >
>> > "The parameters for the 0-RTT data (symmetric cipher suite,
>> > ALPN, etc.) are the same as those which were negotiated in the
>> connection
>> > which established the PSK.  The PSK used to encrypt the early data
>> > MUST be the first PSK listed in the client's "pre_shared_key"
>> extension."
>> > (though I think I just recently added cipher suite).
>> >
>> > and:
>> > "Any ticket MUST only be resumed with a cipher suite that is identical
>> > to that negotiated connection where the ticket was established."
>>
>> If 0-RTT is used with manually provisioned PSKs (might not be allowed
>> currently, but might be allowed soon), does that still hold?
>>
>> Also, I think it is problematic that externally provisioned PSKs can
>> be used with any protection with given prf-hash, while NST-provisioned
>> PSKs can only be used with one protection and prf-hash.
>>
>> 0-RTT requirements are separate matter, since those would apply to all.
>>
>> The original purpose of resumption-as-PSK was AFAIK to unify the two
>> mechanisms to simplify things. Therefore those two should be as similar
>> as possible.
>>
>> >
>> > Also, to straightforwardly prove that collision resistance of HKDF and
>> > > HMAC (as used) follows from collision resistance of the underlying
>> hash
>> > > function, yon need to take the output to be at least the hash output
>> > > size. As otherwise it is not guaranteed that any collision in HKDF or
>> > > HMAC can be reduced into collision of the underlying hash.
>> > >
>> >
>> > Right. I have some text here but please feel free to suggest more.
>>
>> Yes, but the text says 256 bit output is enough. One isn't guaranteed
>> to be able to reduce such collision to collision of >256 bit hash.
>>
>> (In fact, if the hash is e.g. 384 bit, 256-bit collisions are extremely
>> unlikely to reduce).
>>
>
> Right. I can update.
>


​
​I think that allowing truncation (e.g. for SHA-512) with at least 256-bit
output should be fine too without forcing implementations to work with,
say, 512-bit keys.
While I agree that we don't have generic reductions from collision
resistance of a hash function to its truncations, such (long enough)
truncations are believed to inherit collision resistance. For example,
SHA-512 is "officially" allowed to be truncated and it is the way SHA-384
is defined. Also, a collision on a 256-bit truncated output would be a
MAJOR weakness for any hash function, in particular "breaking" the
treatment of the function as a random oracle (such weakness must lead to
abandoning that hash function).

What do cryptanalysts think?

Hugo
​
 ​


>
> -Ekr
>
>
>>
>>
>>
>> -Ilari
>>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS 

Re: [TLS] Finished stuffing/PSK Binders

[Eric Rescorla]

On Sun, Oct 9, 2016 at 8:44 AM, Ilari Liusvaara 
wrote:

> On Sun, Oct 09, 2016 at 07:10:59AM -0700, Eric Rescorla wrote:
> > On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> > > > After the discussion on PR #615, I took another pass at this with
> some
> > > > help from the research community. Please see:
> > > >
> > > >https://github.com/tlswg/tls13-spec/pull/672
> > > >
> > >
> > > Also, an observation: This seems to interact in somewhat annoying way
> > > with stateless HRR.
> > >
> > > Basically, CH reconstruction no longer works properly, so one needs to
> > > have a  freezeable PRF hash (and most implementations of hashes can not
> > > be frozen).
> > >
> >
> > I've been coming to the conclusion that CH reconstruction is a bad idea.
> > It's
> > tricky to get right and in the common case involves a lot of bloat in
> the CH
> > (because of duplicating the Key Shares). I think we would be better off
> just
> > removing it and replacing (rather than appending to ) KeyShares in HRR.
> > This was primarily intended as an attempt to avoid the need to continue
> > the hash in any case.
> >
>
> That creates a bit of a edge case, where the server might need to pull
> client's share accross retry.
>
> (Since if group is OK, the group is not included in HRR, which presumably
> causes the client to blank its KeyShare).
>

I think we would change that rule, probably.

-Ekr


>
>
> Also, doing some size calculations:
>
> ClientHello with "smallest group" rule is ~200 bytes with reasonable
> parameters (I got a dump of one TLS 1.3 draft-16 CH from my TLS stack,
> it is 265 bytes, but would be 196 with "smallest group" rule).
>
> The amount of space needed to freeze (octet) SHA-256 is 32+63+8=103
> octets. And the space needed to freeze (octet) SHA-384 is 64+127+16=207
> bytes (for full SHA-256 and SHA-384, add one more byte).
>
> So if selecting ciphersuite using SHA-384, the state size might be
> comparable to ClientHello size.
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing/PSK Binders

[Ilari Liusvaara]

On Sun, Oct 09, 2016 at 07:10:59AM -0700, Eric Rescorla wrote:
> On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara 
> wrote:
> 
> > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> > > After the discussion on PR #615, I took another pass at this with some
> > > help from the research community. Please see:
> > >
> > >https://github.com/tlswg/tls13-spec/pull/672
> > >
> >
> > Also, an observation: This seems to interact in somewhat annoying way
> > with stateless HRR.
> >
> > Basically, CH reconstruction no longer works properly, so one needs to
> > have a  freezeable PRF hash (and most implementations of hashes can not
> > be frozen).
> >
> 
> I've been coming to the conclusion that CH reconstruction is a bad idea.
> It's
> tricky to get right and in the common case involves a lot of bloat in the CH
> (because of duplicating the Key Shares). I think we would be better off just
> removing it and replacing (rather than appending to ) KeyShares in HRR.
> This was primarily intended as an attempt to avoid the need to continue
> the hash in any case.
> 

That creates a bit of a edge case, where the server might need to pull
client's share accross retry.

(Since if group is OK, the group is not included in HRR, which presumably
causes the client to blank its KeyShare).



Also, doing some size calculations:

ClientHello with "smallest group" rule is ~200 bytes with reasonable
parameters (I got a dump of one TLS 1.3 draft-16 CH from my TLS stack,
it is 265 bytes, but would be 196 with "smallest group" rule).

The amount of space needed to freeze (octet) SHA-256 is 32+63+8=103
octets. And the space needed to freeze (octet) SHA-384 is 64+127+16=207
bytes (for full SHA-256 and SHA-384, add one more byte).

So if selecting ciphersuite using SHA-384, the state size might be
comparable to ClientHello size.


-Ilari

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

Re: [TLS] Finished stuffing/PSK Binders

[Eric Rescorla]

On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara 
wrote:

> On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> > After the discussion on PR #615, I took another pass at this with some
> > help from the research community. Please see:
> >
> >https://github.com/tlswg/tls13-spec/pull/672
> >
>
> Also, an observation: This seems to interact in somewhat annoying way
> with stateless HRR.
>
> Basically, CH reconstruction no longer works properly, so one needs to
> have a  freezeable PRF hash (and most implementations of hashes can not
> be frozen).
>

I've been coming to the conclusion that CH reconstruction is a bad idea.
It's
tricky to get right and in the common case involves a lot of bloat in the CH
(because of duplicating the Key Shares). I think we would be better off just
removing it and replacing (rather than appending to ) KeyShares in HRR.
This was primarily intended as an attempt to avoid the need to continue
the hash in any case.

Best,
-Ekr


And server not supporting PSK does not help here.
>
>
> (BTW: Simlar thing comes up if you try to freeze an established TLS
> session: Currently you need to freeze a hash due to post-handshake
> authentication, even if you don't support it. Nothing else in TLS
> 1.2 or 1.3 needs hash freezing for established session).
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing/PSK Binders

[Ilari Liusvaara]

On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> After the discussion on PR #615, I took another pass at this with some
> help from the research community. Please see:
> 
>https://github.com/tlswg/tls13-spec/pull/672
> 

Also, an observation: This seems to interact in somewhat annoying way
with stateless HRR.

Basically, CH reconstruction no longer works properly, so one needs to
have a  freezeable PRF hash (and most implementations of hashes can not
be frozen).

And server not supporting PSK does not help here.


(BTW: Simlar thing comes up if you try to freeze an established TLS
session: Currently you need to freeze a hash due to post-handshake
authentication, even if you don't support it. Nothing else in TLS
1.2 or 1.3 needs hash freezing for established session).


-Ilari

___
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

[John Mattsson]

Hi Peter,

Yes, it should end with ...SHA384. We will fix this in the next update.
(Related question from Martin Thompson can be found in [0])

Cheers,
John

[0] https://www.ietf.org/mail-archive/web/tls/current/msg21517.html



On 10/07/16 12:51, "TLS on behalf of Peter Dettman"  wrote:

>Hi,
>I've just implemented these ciphersuites in BouncyCastle TLS, and have a
>couple of questions:
>
>In Section 3., should
>
>   TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 = {0xTBD,0xTBD};
>
>end with ...SHA384 instead?
>
>   For the AES-256 cipher suites, the TLS PRF with SHA-384 as the hash
>   function SHALL be used and Clients and Servers MUST NOT negotiate
>   curves of less than 384 bits.
>
>requires SHA384 as the PRF, and I don't know what else SHA256 could
>refer to for an AEAD ciphersuite.
>
>I'm also curious whether there is a precedent in other RFCs for an
>explicit minimum curve bits, or perhaps a de facto implementer's rule?
>
>Regards,
>Pete Dettman
>
>On 28/05/2016 12:19 AM, internet-dra...@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 of the IETF.
>> 
>> Title   : ECDHE_PSK with AES-GCM and AES-CCM Cipher
>>Suites for Transport Layer Security (TLS)
>> Authors : John Mattsson
>>   Daniel Migault
>>  Filename: draft-ietf-tls-ecdhe-psk-aead-00.txt
>>  Pages   : 7
>>  Date: 2016-05-27
>> 
>> Abstract:
>>This document defines several new cipher suites for the Transport
>>Layer Security (TLS) protocol.  The cipher suites are all based on
>>the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
>>(ECDHE_PSK) key exchange together with the Authenticated Encryption
>>with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
>>provides light and efficient authentication, ECDHE provides perfect
>>forward secrecy, and AES-GCM and AES-CCM provides encryption and
>>integrity protection.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-00
>> 
>> 
>> 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
>> 
>
>___
>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

[John Mattsson]

Hi Dan, Sean, Nikos,

First, let me state that I think requiring 128-bit key management for
AES-128 is quite reasonable.

HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applies
when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key sizes
smaller than the lower limits as a connection error (Section 5.4.1
) of type
INADEQUATE_SECURITY."


I think this is a question for TLS in general,
draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decides
as the general way forward. Wether that is MAY/SHOULD/SHALL treat groups
with insufficient security as an error.

I think the real problem here are TLS libraries supporting 1024 MODP and
160 ECC at all, support for these should have been removed before 2010.
Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2
(i.e. WeakDH DieDieDie!!!). I think this is a great idea and much better
than bundling it into a code-point assignment RFC. (My current plans for
the next update of 3GPP’s TLS and DTLS profiles is simply to forbid
support of anything weaker than 2048 MODP and 255-bit ECC).

[0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ



Cheers,
John


On 11/07/16 22:26, "TLS on behalf of Dan Harkins"  wrote:

>
>  I'm glad I have to opportunity to make you happy Sean :-)
>
>On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
>> I think I can take this bit:
>>
>> On Jul 10, 2016, at 06:51, Peter Dettman
>>
>> wrote:
>>>
>>> I'm also curious whether there is a precedent in other RFCs for an
>>> explicit minimum curve bits, or perhaps a de facto implementer's rule?
>>
>> I'd be happy to be wrong here. but to my knowledge no there's not been
>> an explicit minimum for curve bits.  There have however been similar (at
>> least in my non-cryptographer mind) for RSA key sizes so if we wanted to
>> define an explicit minimum curve bits then we could.
>
>  draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring
>the curves used provide commensurate strength with the ciphersuite
>negotiated. Section 10, "Implementation Considerations", says:
>
>   It is RECOMMENDED that implementations take note of the strength
>   estimates of particular groups and to select a ciphersuite providing
>   commensurate security with its hash and encryption algorithms.  A
>   ciphersuite whose encryption algorithm has a keylength less than the
>   strength estimate, or whose hash algorithm has a blocksize that is
>   less than twice the strength estimate SHOULD NOT be used.
>
>  And I would like to take this opportunity to remind everyone that
>the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
>and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant
>to dictionary attack and the former is not.
>
>  regards,
>
>  Dan.
>
>
>
>___
>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