Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

[Tony Arcieri]

On Mon, Feb 13, 2017 at 3:21 PM, Aaron Zauner  wrote:

> I thought the cited paper sorted this out like a year ago.
>
> In favor of option a


I am also in favor of option A.

The wording in option B is simultaneously much more unclear and much more
verbose. I consider it a regression.

Option C is more similar to option A, but not an improvement, IMO.

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

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

[Aaron Zauner]

> On 10 Feb 2017, at 07:07, Sean Turner  wrote:
> 
> All,
> 
> We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 
> Section 5.5 “Limits on Key Usage”.  As it relates to rekeying, these limits 
> have been discussed a couple of times and we need to resolve once and for all 
> whether the TLS WG wants to:
> 
> a) Close these two PRs and go with the existing text [0]

I thought the cited paper sorted this out like a year ago.

In favor of option a

Aaron


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Closing out the final issue in 4492bis

[Sean Turner]

All,

The changes made to draft-ietf-tls-rfc4492bis-11 addressed the WGLC comments, 
but we were waiting to hear from the CFRG wrt whether to use contexts.  It 
appears that the CFRG thread discussing the use of context for TLS1.3 has wound 
down [0] and it appears that the consensus is: “no to contexts in this 
instance”; while the thread did continue for bit nobody was demanding context 
MUST be used in TLS1.3.  Based on this, we’re going to close this final issue 
out.


Yoav - please submit a -12 to address this.  I believe the text you suggest in 
mid-November for s2 would suffice:

 The context parameter for Ed448 MUST be set to the empty string.

Please also note that the 3rd to last paragraph in the security considerations 
needs to be expanded or removed.

Cheers,

J

[0] https://mailarchive.ietf.org/arch/msg/cfrg/LYK6Is9s6fRmniRhVoieYdzdXGw 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

[Dang, Quynh (Fed)]

Hi Markulf,

The probability of a bad thing to happen is actually below (or about) 2^(-33). 
It practically won’t happen when the chance is 1 in 2^32. And, to achieve that 
chance, you must collect 2^48 128-bit blocks.

Regards,
Quynh.

From: TLS > on behalf of 
Markulf Kohlweiss >
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" 
>, Sean Turner 
>
Cc: Antoine Delignat-Lavaud >, 
IRTF CFRG >, 
">" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Hello,

Our analysis of miTLS also supports option a)

A security level of 2^-32 seems too low from a provable security point of view, 
especially for a confidentiality bound.

We verified an implementation of the TLS 1.3 record 
(https://eprint.iacr.org/2016/1178, to appear at Security & Privacy 2017) where 
we arrive at a combined bound for authenticity and confidentiality that is 
compatible with the Iwata et al. bound.

Regards,
Markulf (for the miTLS team)

Hi,

My preference is to go with the existing text, option a).

>From the github discussion, I think option c) involves a less conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
aware of the weaker security guarantees it provides.

I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security proof
for AES-GCM.

Regards,

Kenny

On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
 wrote:

On 10 February 2017 at 16:07, Sean Turner  wrote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]


a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).

I could live with c, but I'm opposed to b. It just doesn't make sense.
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.

___
Cfrg mailing list
Cfrg at irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

___
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] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

[Markulf Kohlweiss]

Hello,

Our analysis of miTLS also supports option a)

A security level of 2^-32 seems too low from a provable security point of view, 
especially for a confidentiality bound.

We verified an implementation of the TLS 1.3 record 
(https://eprint.iacr.org/2016/1178, to appear at Security & Privacy 2017) where 
we arrive at a combined bound for authenticity and confidentiality that is 
compatible with the Iwata et al. bound.

Regards,
Markulf (for the miTLS team)

>Hi,
>
>My preference is to go with the existing text, option a).
>
>From the github discussion, I think option c) involves a less conservative
>security bound (success probability for IND-CPA attacker bounded by
>2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
>aware of the weaker security guarantees it provides.
>
>I do not understand option b). It seems to rely on an analysis of
>collisions of ciphertext blocks rather than the established security proof
>for AES-GCM.
>
>Regards,
>
>Kenny
>
>On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
> wrote:
>
>>On 10 February 2017 at 16:07, Sean Turner  wrote:
>>> a) Close these two PRs and go with the existing text [0]
>>> b) Adopt PR#765 [1]
>>> c) Adopt PR#769 [2]
>>
>>
>>a) I'm happy enough with the current text (I've implemented that any
>>it's relatively easy).
>>
>>I could live with c, but I'm opposed to b. It just doesn't make sense.
>>It's not obviously wrong any more, but the way it is written it is
>>very confusing and easily open to misinterpretation.
>>
>>___
>>Cfrg mailing list
>>Cfrg at irtf.org
>>https://www.irtf.org/mailman/listinfo/cfrg

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

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

[Cas Cremers]

Thanks everyone, we will try to wrap up the situation and remaining issues.

TL;DR:
The problem that we identified applies to fewer situations in the real
protocol than we thought, because of our previously coarse modelling of the
AEAD. However, the main issue remains: the client never receives an in-band
confirmation that the client authentication has succeeded. From a formal
perspective this means there can be a mismatch between the view of the
client and the server. We suggest this is made explicit in the security
guarantees section.

Furthermore, supposing the client has a way to determine whether
authentication was successful, there still exists the possibility that the
client receives messages whose context is ambiguous. In more detail:

   1. Ordering of messages, which is enforced by the AEAD, means that
   property (A) we discussed is not an issue. The client knows that any
   message sent after the certificate will arrive (be processed) at the
   server after the certificate.
   2. Property (B) is still an open issue for both the initial handshake
   and post-handshake. Application messages sent by the server can easily
   be delayed (by network or adversary) and the client cannot determine
   whether this message was sent before or after the authentication was
   received and therefore under the assumption that the client is an
   authenticated peer or not.
   3. There is a small asymmetry between the initial handshake and
   post-handshake. If the client authenticates in the initial handshake,
   receiving post-handshake messages (such as a NewSessionTicket), must
   come after the client's certificate/finished is processed. This is enforced
   cryptographically since the RMS is computed using the Finished messages. In
   contrast, NST messages can arrive ambiguously before/after a post-handshake
   client authentication.

The main takeaway is that the client never really receives any
acknowledgement of whether the verification provided was successful or
rejected through an in-band mechanism.

The context of the keys does not include the client’s authentication status
(nor the client’s certificate), and is the same in both cases. From a
formal analysis point of view, this results in a mismatch where the client
and server may not agree on the mutual authentication status, which is the
main point we wanted to raise.

Assuming now that the key context will not be changed, we suggest to
explicitly mention in the security guarantees section that the client,
after sending authentication messages, cannot be sure at any point that the
server has received these messages and considers the connection to be
mutually authenticated. If the client wishes to obtain such a guarantee, it
has to be informed by the server’s application.

Best,

Cas Cremers,
Marko Horvat,
Jonathan Hoyland,
Thyla van der Merwe, and
Sam Scott
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls