On Thu, Feb 25, 2016 at 10:20 PM, Watson Ladd wrote:
> On Thu, Feb 25, 2016 at 11:54 AM, Hugo Krawczyk
> wrote:
> > As I said in another email, without client authentication (which is the
> > scenario in the Karthik quote), data sent by the server should be
> considered
> > secure only against p
On Thu, Feb 25, 2016 at 11:54 AM, Hugo Krawczyk wrote:
> As I said in another email, without client authentication (which is the
> scenario in the Karthik quote), data sent by the server should be considered
> secure only against passive adversaries. Any additional assumption on
> confidentiality
On Thu, Feb 25, 2016 at 9:55 PM, Antoine Delignat-Lavaud <
anto...@delignat-lavaud.fr> wrote:
> Le 2016-02-25 12:29, m...@sap.com a écrit :
>
>> Karthikeyan Bhargavan wrote:
>>
>>>
>>> Yes Hugo, you?re right that when there is no client auth,
>>> the situation is less problematic.
>>>
>>
>> I'm no
As I said in another email, without client authentication (which is the
scenario in the Karthik quote), data sent by the server should be
considered secure only against passive adversaries. Any additional
assumption on confidentiality (i.e., restricting the power of an active
attacker) must conside
Le 2016-02-25 12:29, m...@sap.com a écrit :
Karthikeyan Bhargavan wrote:
Yes Hugo, you?re right that when there is no client auth,
the situation is less problematic.
I'm not so sure.
QUIC gives a pretty good idea of how 0-RTT is going to be used in
browsers: they will almost certainly send
Watson Ladd wrote:
>
> But will they call tls_send_data_replayable?
The proper name would be tls_send_data_replayable_and_NO_forward_secrecy.
-Martin
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Karthikeyan Bhargavan wrote:
>
> Yes Hugo, you?re right that when there is no client auth,
> the situation is less problematic.
I'm not so sure.
There might be the desire of the server to keep some data confidential,
and your argument is that if the data wasn't confidential to begin with,
the s
I was trying to articulate what does the analysis in OPTLS that does not
include the client's Finished message (or client authentication) means in
practical terms for 0.5-RTT data. I think that one way to put it is that
for the server it guarantees confidentiality against passive (only)
attackers a
On Tue Feb 23 19:28:12 2016 GMT-0800, Watson Ladd wrote:
> On Tue, Feb 23, 2016 at 5:49 PM, Stephen Farrell
> wrote:
> >
> >
> > On 23/02/16 22:37, Hugo Krawczyk wrote:
> >>
> >> (In particular, if these semantics may be based on stuff that happens
> >> outside TLS, as Karthik and Watson were po
On Tue, Feb 23, 2016 at 5:49 PM, Stephen Farrell
wrote:
>
>
> On 23/02/16 22:37, Hugo Krawczyk wrote:
>>
>> (In particular, if these semantics may be based on stuff that happens
>> outside TLS, as Karthik and Watson were pointing out, then maybe we really
>> put a "Surgeon General" warning on 0.5
On 23/02/16 22:37, Hugo Krawczyk wrote:
>
> (In particular, if these semantics may be based on stuff that happens
> outside TLS, as Karthik and Watson were pointing out, then maybe we really
> put a "Surgeon General" warning on 0.5 data of equal size to that of 0-RTT.)
That, and/or also do a si
On 23 February 2016 at 14:37, Hugo Krawczyk wrote:
> It seems to imply that you are attaching some "client-specific semantics"
> even to keys that were not authenticated by the client.
It's primarily a privacy concern, though it's a pretty weak concern.
__
On Tue, Feb 23, 2016 at 5:08 PM, Martin Thomson
wrote:
> On 23 February 2016 at 14:01, Karthikeyan Bhargavan
> wrote:
> > The main downgrade concern, I think, is for the 0.5-RTT data’s
> confidentiality; i.e. it may have been sent encrypted under a broken cipher.
>
> Hmm, that's a good point. S
On 23 February 2016 at 14:26, Hugo Krawczyk wrote:
> Karthik, I think that what you are pointing to are cases where the client
> *is* authenticated via its PSK.
In the downgrade scenario, that doesn't seem right, but maybe it's
just that the client's ClientHello is being authenticated.
> Any PSK-based handshake that uses a (previously) client-authenticated PSK
> needs to be treated as client-authenticated and replay needs to be dealt with
> utmost care, including the need to validate via the client finished that the
> current exchange is not a replay. In the case where the PSK
On Feb 23, 2016 2:27 PM, "Hugo Krawczyk" wrote:
>
> Karthik, I think that what you are pointing to are cases where the client
*is* authenticated via its PSK.
>
> There is an important distinction between PSKs that have been
authenticated by the client (in a previous exchange) and those that are no
Karthik, I think that what you are pointing to are cases where the client
*is* authenticated via its PSK.
There is an important distinction between PSKs that have been authenticated
by the client (in a previous exchange) and those that are not.
Any PSK-based handshake that uses a (previously) clie
On 23 February 2016 at 14:01, Karthikeyan Bhargavan
wrote:
> The main downgrade concern, I think, is for the 0.5-RTT data’s
> confidentiality; i.e. it may have been sent encrypted under a broken cipher.
Hmm, that's a good point. So Antoine's analogy is closer to correct
than I had thought, and
> Won't a downgrade be detected by the client when it fails to decrypt
> the server's data?
The main downgrade concern, I think, is for the 0.5-RTT data’s confidentiality;
i.e. it may have been sent encrypted under a broken cipher.
You’re right that the client will not accept this data because t
> That's right, we do not consider downgrades or client authentication but
> Martin's suggestion explicitly only applies to the case where the server
> does not require client authentication so the analysis holds in that case. As
> for downgrades, this will be discovered by the server when rec
On 23 February 2016 at 13:24, Hugo Krawczyk wrote:
> As for downgrades, this will be discovered by the server when receiving the
> client's Finished message.
Won't a downgrade be detected by the client when it fails to decrypt
the server's data? If the server was given a false impression about
t
On Tue, Feb 23, 2016 at 3:49 PM, Karthikeyan Bhargavan <
karthik.bharga...@gmail.com> wrote:
> There are some fears about 0.5-RTT data that do not necessarily apply to
> post-client authentication, at which point at least both parties have sent
> their Finished messages.
>
> When the server is sen
There are some fears about 0.5-RTT data that do not necessarily apply to
post-client authentication, at which point at least both parties have sent
their Finished messages.
When the server is sending 0.5-RTT data, this is effectively false-start; the
client hasn’t confirmed its choice of ciphe
23 matches
Mail list logo
