Re: [TLS] Commentary on the client authentication presentation slides

[Martin Thomson]

Before people get too far down that road, here:

https://tools.ietf.org/html/draft-thomson-httpbis-cant-01
https://tools.ietf.org/html/draft-thomson-tls-care-00

Andrei has made it clear that these do not work for his use case (I'm
not yet convinced that they are inadequate, but I am convinced of the
fact that Andrei thinks that they are inadequate ;).

Also:

https://tools.ietf.org/html/draft-ietf-httpbis-http2-00#section-2.6.9

This is well-trodden ground.

On 10 August 2015 at 23:05, Dave Garrett  wrote:
> On Monday, August 10, 2015 01:10:38 pm Andrei Popov wrote:
>> > What sort of usecase you have in mind for this?
>>
>> This is to support a fairly common website design where the landing page 
>> does not require client auth, but subsequent request to a protected resource 
>> triggers client authentication within an existing TLS connection.
>> In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, there is no 
>> renegotiation, so we need an alternative solution if we want to support 
>> these existing sites over TLS1.3.
>
> This is just an idea, but what about just allowing a renegotiation-like 
> mechanism via 0-RTT with PSK resumption to be triggered on a TLS alert or 
> HTTP response code? The rough idea would be like this:
>
> 1) client connects to server and fetches public resources
> 2) client requests restricted resource; server sends auth required response 
> (TLS alert or HTTP code)
> 3) client creates a replacement connection using PSK-based resumption and 
> early data in the first flight for the request along with the client cert.
>
> There's a 1 roundtrip cost in there for a new TCP connection, which could 
> possibly be optimized away by using TCP fast open.
>
> This general concept is relatively simple in comparison to doing something 
> mid-connection. Instead of attempting to renegotiate on an existing 
> connection, just make creation of resumed connections cheap enough to start 
> over with client auth in the handshake from the start.
>
> It's a very rough idea, but I'm wondering if it sounds like something worth 
> discussing.
>
>
> Dave
>
> ___
> 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] blink intends to drop keygen and application/x-x509* handling

[Henry Story]

I just thought this group would be interested in following the thread on the
blink user group 

"(Pre-)Intent to Deprecate:  element and application/x-x509-*-cert MIME 
handling"

  https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack

dropping those two features of the web without a good replacement would make
TLS client certificate use in browsers immediately a lot more problematic. 
Whether the replacements are there is part of the debate.

I am not sure yet how TLS 3.0 and HTTP2.0 are progressing for client 
authentication.


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

Re: [TLS] [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux

[Christer Holmberg]

Hi,

We shall not make RFC 5764 corrections in the RTCWEB specs.

Regards,

Christer



From: rtcweb [mailto:rtcweb-boun...@ietf.org] On Behalf Of Schwarz, Albrecht 
(Albrecht)
Sent: 5. elokuuta 2015 11:04
To: 
Cc: TLS@ietf.org (tls@ietf.org)
Subject: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the 
gateway draft should say about mux/non-mux

Roman, Bernard,
right, RFC 5764 is too vague on that aspect. Thanks for confirming the number 
of DTLS sessions, which is inline with our understanding.
Would appreciate if this could be somewhere fixed in an rtcweb draft due to 
significant side effects.
This topic is also an ongoing FAQ.

The most simple case is given by a scenario with usage of bundling plus usage 
of RTP/RTCP transport multiplexing, leading to a single DTLS session/DTLS 
connection, which could be then also shared for WebRTC data.

Both capabilities are mandated in the rtp usage draft:
https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.4
=> bundling
https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5
=> RTP/RTCP transport multiplexing

Now, IF bundling is not used OR RTP/RTCP transport multiplexing is not used 
THEN there will be more than one DTLS session/DTLS connection (either 2 or 4 in 
case of audio & video).
Raising the question which DTLS connection is used for additional WebRTC data 
traffic? - Because
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#section-3.5
indicates the sharing option.
Would then be a 3rd (or 5th) self-contained DTLS session/DTLS connection for 
WebRTC data traffic?

Proposal:
Add explicit text to clause 
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#section-3.5
about (in red), something like:

   WebRTC implementations MUST support multiplexing of DTLS and RTP over
   the same port pair, as described in the DTLS-SRTP specification
   [RFC5764], section 5.1.2. 
 All application layer protocol payloads
   over this DTLS connection are SCTP packets.



   Note 1: There will be two DTLS sessions/DTLS connections when RTP/RTCP 
transport multiplexing is not applied. WebRTC data traffic could still share 
one of these DTLS connections … (“which one?”) … or There should be then a 
separate, self-contained DTLS session/DTLS connection established exclusively 
for WebRTC data.



   Note 2: There are similar considerations in case of bundling.

   Protocol identification MUST be supplied as part of the DTLS
   handshake, as specified in 
[I-D.ietf-rtcweb-alpn].

Comments?
Regards,
Albrecht

PS
Using (D)TLS terminology according to 
http://tools.ietf.org/id/draft-guballa-tls-terminology-01.txt


From: Bernard Aboba [mailto:bernard.ab...@gmail.com]
Sent: Mittwoch, 5. August 2015 04:04
To: Roman Shpount
Cc: Asveren, Tolga; Christer Holmberg; Eric Rescorla; Schwarz, Albrecht 
(Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); 
mailto:rtc...@ietf.org>>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

On Aug 4, 2015, at 16:33, Roman Shpount 
mailto:ro...@telurix.com>> wrote:

Most of the people implement this wrong, since you need to create two DTLS 
sessions: one for RTP and another for RTCP. And then use different keys or 
possibly even encryption profiles for RTP and RTCP. I commonly see one session 
for RTP and keys negotiated there used for both RTP and RTCP, which is wrong.

[BA] Yes, that is only one of several common mistakes.  Unfortunately, RFC 5764 
does not rule out all of these and the security documents are not crystal clear 
on how things must be done. It is much harder to mess up RTP/RTCP mux.  Given 
what I've seen so far, non-mux could become a support nightmare.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux

[Christer Holmberg]

Hi,

I guess we could add some clarification text to the SDP-DTLS draft.

Regards,

Christer

From: Asveren, Tolga [mailto:tasve...@sonusnet.com]
Sent: 5. elokuuta 2015 15:27
To: Christer Holmberg; Schwarz, Albrecht (Albrecht); 
Cc: TLS@ietf.org (tls@ietf.org)
Subject: RE: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the 
gateway draft should say about mux/non-mux

Yes, completely agree.

And I think what Albrecht proposes below is the right way of addressing the 
“no-rtcp-mux implementation difficulties” problem: Adding 
clarifications/amendments in the respective normative specification rather than 
disallowing a combination in a profile because it is “confusing”.
Honestly, I think the number of DTLS connections to use, when bundling/muxing 
is not used, is not really that hard to figure out (for somebody who actually 
understands the whole story) but obviously no harm of adding some 
clarifications. DataChannel aspects need to be crisply specified though. What 
is the main advantage of letting DataChannel potentially use one of the 
exsiting DTLS connections? Just to save some time on negotiation?

Thanks,
Tolga

From: rtcweb [mailto:rtcweb-boun...@ietf.org] On Behalf Of Christer Holmberg
Sent: Wednesday, August 05, 2015 4:13 AM
To: Schwarz, Albrecht (Albrecht) 
mailto:albrecht.schw...@alcatel-lucent.com>>;
 mailto:rtc...@ietf.org>> 
mailto:rtc...@ietf.org>>
Cc: TLS@ietf.org (tls@ietf.org) 
mailto:tls@ietf.org>>
Subject: Re: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the 
gateway draft should say about mux/non-mux

Hi,

We shall not make RFC 5764 corrections in the RTCWEB specs.

Regards,

Christer



From: rtcweb [mailto:rtcweb-boun...@ietf.org] On Behalf Of Schwarz, Albrecht 
(Albrecht)
Sent: 5. elokuuta 2015 11:04
To: mailto:rtc...@ietf.org>>
Cc: TLS@ietf.org (tls@ietf.org)
Subject: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the 
gateway draft should say about mux/non-mux

Roman, Bernard,
right, RFC 5764 is too vague on that aspect. Thanks for confirming the number 
of DTLS sessions, which is inline with our understanding.
Would appreciate if this could be somewhere fixed in an rtcweb draft due to 
significant side effects.
This topic is also an ongoing FAQ.

The most simple case is given by a scenario with usage of bundling plus usage 
of RTP/RTCP transport multiplexing, leading to a single DTLS session/DTLS 
connection, which could be then also shared for WebRTC data.

Both capabilities are mandated in the rtp usage draft:
https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.4
=> bundling
https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5
=> RTP/RTCP transport multiplexing

Now, IF bundling is not used OR RTP/RTCP transport multiplexing is not used 
THEN there will be more than one DTLS session/DTLS connection (either 2 or 4 in 
case of audio & video).
Raising the question which DTLS connection is used for additional WebRTC data 
traffic? - Because
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#section-3.5
indicates the sharing option.
Would then be a 3rd (or 5th) self-contained DTLS session/DTLS connection for 
WebRTC data traffic?

Proposal:
Add explicit text to clause 
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#section-3.5
about (in red), something like:

   WebRTC implementations MUST support multiplexing of DTLS and RTP over
   the same port pair, as described in the DTLS-SRTP specification
   [RFC5764], section 5.1.2. 
 All application layer protocol payloads
   over this DTLS connection are SCTP packets.



   Note 1: There will be two DTLS sessions/DTLS connections when RTP/RTCP 
transport multiplexing is not applied. WebRTC data traffic could still share 
one of these DTLS connections … (“which one?”) … or There should be then a 
separate, self-contained DTLS session/DTLS connection established exclusively 
for WebRTC data.



   Note 2: There are similar considerations in case of bundling.

   Protocol identification MUST be supplied as part of the DTLS
   handshake, as specified in 
[I-D.ietf-rtcweb-alpn].

Comments?
Regards,
Albrecht

PS
Using (D)TLS terminology according to 
http://tools.ietf.org/id/draft-guballa-tls-terminology-01.txt


From: Bernard Aboba [mailto:bernard.ab...@gmail.com]
Sent: Mittwoch, 5. August 2015 04:04
To: Roman Shpount
Cc: Asveren, Tolga; Christer Holmberg; Eric Rescorla; Schwarz, Albrecht 
(Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); 
mailto:rtc...@ietf.org>>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

On Aug 4, 2015, at 16:33, Roman Shpount 
mailto:ro...@telurix.com>> wrote:

Most of the people implement this wrong, since you need to create two DTLS 
sessions: one for RTP and another for RTCP.

Re: [TLS] [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux

[Asveren, Tolga]

Yes, completely agree.

And I think what Albrecht proposes below is the right way of addressing the 
“no-rtcp-mux implementation difficulties” problem: Adding 
clarifications/amendments in the respective normative specification rather than 
disallowing a combination in a profile because it is “confusing”.
Honestly, I think the number of DTLS connections to use, when bundling/muxing 
is not used, is not really that hard to figure out (for somebody who actually 
understands the whole story) but obviously no harm of adding some 
clarifications. DataChannel aspects need to be crisply specified though. What 
is the main advantage of letting DataChannel potentially use one of the 
exsiting DTLS connections? Just to save some time on negotiation?

Thanks,
Tolga

From: rtcweb [mailto:rtcweb-boun...@ietf.org] On Behalf Of Christer Holmberg
Sent: Wednesday, August 05, 2015 4:13 AM
To: Schwarz, Albrecht (Albrecht) ; 
 
Cc: TLS@ietf.org (tls@ietf.org) 
Subject: Re: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the 
gateway draft should say about mux/non-mux

Hi,

We shall not make RFC 5764 corrections in the RTCWEB specs.

Regards,

Christer



From: rtcweb [mailto:rtcweb-boun...@ietf.org] On Behalf Of Schwarz, Albrecht 
(Albrecht)
Sent: 5. elokuuta 2015 11:04
To: mailto:rtc...@ietf.org>>
Cc: TLS@ietf.org (tls@ietf.org)
Subject: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the 
gateway draft should say about mux/non-mux

Roman, Bernard,
right, RFC 5764 is too vague on that aspect. Thanks for confirming the number 
of DTLS sessions, which is inline with our understanding.
Would appreciate if this could be somewhere fixed in an rtcweb draft due to 
significant side effects.
This topic is also an ongoing FAQ.

The most simple case is given by a scenario with usage of bundling plus usage 
of RTP/RTCP transport multiplexing, leading to a single DTLS session/DTLS 
connection, which could be then also shared for WebRTC data.

Both capabilities are mandated in the rtp usage draft:
https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.4
=> bundling
https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5
=> RTP/RTCP transport multiplexing

Now, IF bundling is not used OR RTP/RTCP transport multiplexing is not used 
THEN there will be more than one DTLS session/DTLS connection (either 2 or 4 in 
case of audio & video).
Raising the question which DTLS connection is used for additional WebRTC data 
traffic? - Because
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#section-3.5
indicates the sharing option.
Would then be a 3rd (or 5th) self-contained DTLS session/DTLS connection for 
WebRTC data traffic?

Proposal:
Add explicit text to clause 
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#section-3.5
about (in red), something like:

   WebRTC implementations MUST support multiplexing of DTLS and RTP over
   the same port pair, as described in the DTLS-SRTP specification
   [RFC5764], section 5.1.2. 
 All application layer protocol payloads
   over this DTLS connection are SCTP packets.



   Note 1: There will be two DTLS sessions/DTLS connections when RTP/RTCP 
transport multiplexing is not applied. WebRTC data traffic could still share 
one of these DTLS connections … (“which one?”) … or There should be then a 
separate, self-contained DTLS session/DTLS connection established exclusively 
for WebRTC data.



   Note 2: There are similar considerations in case of bundling.

   Protocol identification MUST be supplied as part of the DTLS
   handshake, as specified in 
[I-D.ietf-rtcweb-alpn].

Comments?
Regards,
Albrecht

PS
Using (D)TLS terminology according to 
http://tools.ietf.org/id/draft-guballa-tls-terminology-01.txt


From: Bernard Aboba [mailto:bernard.ab...@gmail.com]
Sent: Mittwoch, 5. August 2015 04:04
To: Roman Shpount
Cc: Asveren, Tolga; Christer Holmberg; Eric Rescorla; Schwarz, Albrecht 
(Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); 
mailto:rtc...@ietf.org>>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

On Aug 4, 2015, at 16:33, Roman Shpount 
mailto:ro...@telurix.com>> wrote:

Most of the people implement this wrong, since you need to create two DTLS 
sessions: one for RTP and another for RTCP. And then use different keys or 
possibly even encryption profiles for RTP and RTCP. I commonly see one session 
for RTP and keys negotiated there used for both RTP and RTCP, which is wrong.

[BA] Yes, that is only one of several common mistakes.  Unfortunately, RFC 5764 
does not rule out all of these and the security documents are not crystal clear 
on how things must be done. It is much harder to mess up RTP/RTCP mux.  Given 
what I've seen so far, non-mux could become a support nightmare.
___

[TLS] TLS and KCI vulnerable handshakes

[Clemens Hlauschek]

Hi,

I published a paper today on KCI-attacks in TLS. This might be of
interest to the TLS WG.

https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek

Regards,
Clemens

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

[TLS] TLS Handshake message length too long

[dott...@gmail.com]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have a question regarding the handshake message length.

The 'decode_error' alert in TLS 1.2 is defined as:

   decode_error
  A message could not be decoded because some field was out of the
  specified range or the length of the message was incorrect. (...)

It says that the message "could not be decoded". What should happen
if the specified message length is longer than needed? I.e. the message
was successfully decoded, but the length of the message was incorrect:
there is still some unknown data after the defined structure.

For example, a Finished message has a length of 40 bytes,
but the 'verify_data' array has 32 bytes and there are 8 unknown bytes
remaining in the received message. The 40 bytes I talk about here
is the length specified in the Handshake message header.

Is this also a fatal error?
Should the implementation just drop those bytes and proceed?

On the other hand, there is the 'illegal_parameter' alert:

   illegal_parameter
  A field in the handshake was out of range or inconsistent with
  other fields.  This message is always fatal.

Is this alert suitable for the described scenario?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVx2aPAAoJEDRBz9VZHKuWFOMP/iUyc0+sdyV24EAwCLxSE7+i
pv8cA/TIodpH828p0wgrg+hCWCEB39gH3WMJsw9T4ItRKZZ8B8dFTnrtAWQa3smL
Z+YNCH1wcl03IuF67W0YjMUTPCIFiY0WwYBOI+GIcYzwse7vW+it5hOfILjM1705
1P2DqILZ8mJtrR5GoVKZAor+ynjTUfkrQl7yrR7dz2wpNK4vdgY/UHXupSNLt2QS
lirkzKsUazfZQLzDggNfmUfCugFle3PFatqQShPeSI9QBEO+7rlAgGzPV5FiKPxI
+YxJcQIHvEv47caUp9uv8B/3N2L6RhHSHYNjMaBHGzI+BWGfBq0cjv07HIyvtgzg
fEZJ+5g9hfWjeDSCQ6wYT6G5io5RxydKKkP+Gunbz9FvLNoz7wdK6b7t/pdQXzqh
kp0xXXZfF/psulxIOHmzF3xlGsHz+8iudulNm2OavXBUKXOZFr4QPO6l8wU1KWZ2
6tS2s6c0Hhfyd+lI5w2cP6zFbavmxUzRVd2hkKakIpr18KGEZfIE0eZW9bOvmB32
3nSD1+KLVZDHFAcS2lGH5ubSKbnJl7979j0XZVloi5zfgTCNWES2lffwXABdyvQ5
S5HWnUsPoQCJ98ypp+SEShqFbb0GRjTvZIRpxeb8j2w0onNg2QQCQs6tENaQzYEL
tvDaK+aq+empNxAVbMBP
=3KMw
-END PGP SIGNATURE-

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Peter Gutmann]

Clemens Hlauschek  writes:

>I published a paper today on KCI-attacks in TLS. This might be of interest to
>the TLS WG.
>
>https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek

Some comments on this, it looks like it requires a "cert with static (EC)DH
key" in order to work, which would mean an X9.42 cert.  Since no (public) CA
that I know of can handle or issue such certs, this probably provides a
reasonable amount of defence against this attack...

In terms of the suggested countermeasures:

>Set appropriate X509 Key Usage extension for ECDSA and DSS certificates, and
>disable specifically the KeyAgreement flag

Since the keyUsage flags are widely ignored by implementations, this won't
provide the protection that the text implies.

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

Re: [TLS] Commentary on the client authentication presentation slides

[Andrei Popov]

Indeed, I think cant-care has a number of disadvantages:
1. Introduces round-trips to establish a new TCP connection;
2. Requires a new TLS handshake, with associated costs.
3. Uses two CertificateRequests: one at the HTTP layer, and another at the TLS 
layer. Somehow we would need to figure out how to make them match, or have the 
client ignore TLS-level cert filtering parameters?
4. Pushes the problem to the application layer: any application protocol that 
uses mid-stream client auth will require an update. (I know, some will say we 
are only aware of HTTPS scenarios right now.)

At the cost of all of the above, cant-care allows the client to determine 
exactly which HTTP request has resulted in the client auth request. I think 
there may be a compromise where we can identify this HTTP request without 
requiring a reconnect. E.g. what about CertificateRequest at the HTTP layer + 
TLS client sending Certificate/CertificateVerify after the handshake in the 
middle of the existing TLS connection?

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson
Sent: Tuesday, August 11, 2015 9:39 AM
To: Dave Garrett 
Cc: tls@ietf.org
Subject: Re: [TLS] Commentary on the client authentication presentation slides

Before people get too far down that road, here:

https://tools.ietf.org/html/draft-thomson-httpbis-cant-01
https://tools.ietf.org/html/draft-thomson-tls-care-00

Andrei has made it clear that these do not work for his use case (I'm not yet 
convinced that they are inadequate, but I am convinced of the fact that Andrei 
thinks that they are inadequate ;).

Also:

https://tools.ietf.org/html/draft-ietf-httpbis-http2-00#section-2.6.9

This is well-trodden ground.

On 10 August 2015 at 23:05, Dave Garrett  wrote:
> On Monday, August 10, 2015 01:10:38 pm Andrei Popov wrote:
>> > What sort of usecase you have in mind for this?
>>
>> This is to support a fairly common website design where the landing page 
>> does not require client auth, but subsequent request to a protected resource 
>> triggers client authentication within an existing TLS connection.
>> In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, there is no 
>> renegotiation, so we need an alternative solution if we want to support 
>> these existing sites over TLS1.3.
>
> This is just an idea, but what about just allowing a renegotiation-like 
> mechanism via 0-RTT with PSK resumption to be triggered on a TLS alert or 
> HTTP response code? The rough idea would be like this:
>
> 1) client connects to server and fetches public resources
> 2) client requests restricted resource; server sends auth required 
> response (TLS alert or HTTP code)
> 3) client creates a replacement connection using PSK-based resumption and 
> early data in the first flight for the request along with the client cert.
>
> There's a 1 roundtrip cost in there for a new TCP connection, which could 
> possibly be optimized away by using TCP fast open.
>
> This general concept is relatively simple in comparison to doing something 
> mid-connection. Instead of attempting to renegotiate on an existing 
> connection, just make creation of resumed connections cheap enough to start 
> over with client auth in the handshake from the start.
>
> It's a very rough idea, but I'm wondering if it sounds like something worth 
> discussing.
>
>
> Dave
>
> ___
> 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] TLS and KCI vulnerable handshakes

[Karthikeyan Bhargavan]

>> https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek
> 
> Some comments on this, it looks like it requires a "cert with static (EC)DH
> key" in order to work, which would mean an X9.42 cert.  Since no (public) CA
> that I know of can handle or issue such certs, this probably provides a
> reasonable amount of defence against this attack…

No, a regular ECDSA certificate would do.
That is, the attack would work as long as 
- a client has an ECDSA certificate, and
- it enables any static TLS_ECDH_* cipher suite, and
- its ECDSA private key has been stolen (or chosen) by an attacker.

Best,
Karthik


> 
> In terms of the suggested countermeasures:
> 
>> Set appropriate X509 Key Usage extension for ECDSA and DSS certificates, and
>> disable specifically the KeyAgreement flag
> 
> Since the keyUsage flags are widely ignored by implementations, this won't
> provide the protection that the text implies.
> 
> Peter.
> ___
> 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] TLS and KCI vulnerable handshakes

[Martin Thomson]

On 11 August 2015 at 11:25, Karthikeyan Bhargavan
 wrote:
> No, a regular ECDSA certificate would do.
> That is, the attack would work as long as
> - a client has an ECDSA certificate, and
> - it enables any static TLS_ECDH_* cipher suite, and
> - its ECDSA private key has been stolen (or chosen) by an attacker.

I don't see how that would work.  A client that understands the cert
to be ECDSA won't pair the key with the server's ECDH share, they will
sign the session transcript with it.

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Ilari Liusvaara]

On Tue, Aug 11, 2015 at 11:29:12AM -0700, Martin Thomson wrote:
> On 11 August 2015 at 11:25, Karthikeyan Bhargavan
>  wrote:
> > No, a regular ECDSA certificate would do.
> > That is, the attack would work as long as
> > - a client has an ECDSA certificate, and
> > - it enables any static TLS_ECDH_* cipher suite, and
> > - its ECDSA private key has been stolen (or chosen) by an attacker.
> 
> I don't see how that would work.  A client that understands the cert
> to be ECDSA won't pair the key with the server's ECDH share, they will
> sign the session transcript with it.

a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is
no ECDSA-specific keytype in X.509.

b) SSL v3.0 server PoP (still there in TLS v1.2) does not sign
transcript but only the public key (only TLS 1.3 fixes this).
Logjam, anyone?

c) Non-signature client certs (like ECDH) don't have transcript
signatures either.


Attacker can just replay randoms and SKE, and then compute client-
side PMS. Game Over, EMS will not save you.



-Ilari

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Martin Thomson]

On 11 August 2015 at 12:05, Ilari Liusvaara  wrote:
>> I don't see how that would work.  A client that understands the cert
>> to be ECDSA won't pair the key with the server's ECDH share, they will
>> sign the session transcript with it.
>
> a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is
> no ECDSA-specific keytype in X.509.

Maybe I should have been clearer.  The certificate might not include a
(strong) signal that allows the client to distinguish between ECDSA
and fixed ECDH, but the client might be configured with that
knowledge.

I checked NSS and there doesn't seem to be any way that it could be
coerced into using the (EC)DH pair from a client certificate in a key
exchange.  Even though it supports some fixed (EC)DH suites.

NSS (incorrectly) adopts the posture that _ECDH_ suites are
half-static: the server share is in the certificate, but the client
side is fully ephemeral.  This is clearly in violation of RFC 5246,
Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about
that right now :)

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Clemens Hlauschek]

On 08/11/2015 05:06 PM, Martin Thomson wrote:
> On 11 August 2015 at 12:05, Ilari Liusvaara  
> wrote:
>>> I don't see how that would work.  A client that understands the cert
>>> to be ECDSA won't pair the key with the server's ECDH share, they will
>>> sign the session transcript with it.
>>
>> a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is
>> no ECDSA-specific keytype in X.509.
> 
> Maybe I should have been clearer.  The certificate might not include a
> (strong) signal that allows the client to distinguish between ECDSA
> and fixed ECDH, but the client might be configured with that
> knowledge.


There is no difference between an ECDH and an ECDSA, apart from
(possibly) the KeyUsage Extension.


> 
> I checked NSS and there doesn't seem to be any way that it could be
> coerced into using the (EC)DH pair from a client certificate in a key
> exchange.  Even though it supports some fixed (EC)DH suites.


To the best of our knowledge, NSS does not support fixed ECDH client
authentication. I checked the code manually. Prof Matt Green also
verified with EKR at Mozilla during the pre-public disclosure phase that
NSS is not vulnerable.


> 
> NSS (incorrectly) adopts the posture that _ECDH_ suites are
> half-static: the server share is in the certificate, but the client
> side is fully ephemeral.  This is clearly in violation of RFC 5246,
> Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about
> that right now :)
> 


Please elaborate. I do not see how this half-static behaviour
constitutes any violations of the mentioned RFCs. I would say
half-static ECDH handshake is not only fully spec conforming, but *the*
way to do an ECDH handshake when client authentication (*_fixed_(ec)dh)
is not requested by the server. OpenSSL, as well as other
implementations, do the same.


Clemens

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Martin Thomson]

On 11 August 2015 at 16:38, Clemens Hlauschek
 wrote:
>> Maybe I should have been clearer.  The certificate might not include a
>> (strong) signal that allows the client to distinguish between ECDSA
>> and fixed ECDH, but the client might be configured with that
>> knowledge.
>
> There is no difference between an ECDH and an ECDSA, apart from
> (possibly) the KeyUsage Extension.

I'l try again.  Even if the certificate does not include that signal,
the software that accepts that signal might make assumptions or have
configuration that cause it to only be used in one way or another.
See NSS.

>> NSS (incorrectly) adopts the posture that _ECDH_ suites are
>> half-static: the server share is in the certificate, but the client
>> side is fully ephemeral.  This is clearly in violation of RFC 5246,
>> Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about
>> that right now :)
>
> Please elaborate. I do not see how this half-static behaviour
> constitutes any violations of the mentioned RFCs.

Both the above cited sections say very clearly that for fixed (EC)DH
cipher suites the client where the client has a fixed (EC)DH
certificate, the client MUST send an empty ClientKeyExchange.

Of course, you might say that this is simply a consequence of not
supporting fixed (EC)DH for client authentication, and then it's not
technically in violation.  The value of the ClientCertificateType from
the CertificateRequest is likely important here, but that field is
systematically ignored in practice (NSS ignores it).

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Daniel Kahn Gillmor]

On Tue 2015-08-11 19:59:35 -0400, Martin Thomson wrote:
> On 11 August 2015 at 16:38, Clemens Hlauschek 
>  wrote:
 [ MT wrote: ]
>>> NSS (incorrectly) adopts the posture that _ECDH_ suites are
>>> half-static: the server share is in the certificate, but the client
>>> side is fully ephemeral.  This is clearly in violation of RFC 5246,
>>> Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about
>>> that right now :)
>>
>> Please elaborate. I do not see how this half-static behaviour
>> constitutes any violations of the mentioned RFCs.
>
> Both the above cited sections say very clearly that for fixed (EC)DH
> cipher suites the client where the client has a fixed (EC)DH
> certificate, the client MUST send an empty ClientKeyExchange.

that's not how i'm reading 5246 §7.4.7  -- i see it as saying if the
client has decided to send a fixed (EC)DH cert, then it MUST send an
empty ClientKey Exchange.

I see no requirement that a client MUST send a certificate if it has one
that satisfies the server's CertificateRequest (and i would be strongly
opposed to adding such a requirement -- clients should not be forced to
reveal identity to a server just because of CertificateRequest message
in the handshake).

so i think NSS is doing the Right Thing here too.

   --dkg

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Clemens Hlauschek]

On 08/11/2015 07:59 PM, Martin Thomson wrote:
> On 11 August 2015 at 16:38, Clemens Hlauschek
>  wrote:
>>> Maybe I should have been clearer.  The certificate might not include a
>>> (strong) signal that allows the client to distinguish between ECDSA
>>> and fixed ECDH, but the client might be configured with that
>>> knowledge.
>>
>> There is no difference between an ECDH and an ECDSA, apart from
>> (possibly) the KeyUsage Extension.
> 
> I'l try again.  Even if the certificate does not include that signal,
> the software that accepts that signal might make assumptions or have
> configuration that cause it to only be used in one way or another.
> See NSS.

NSS does not support

rsa_fixed_ecdh
ecdsa_fixed_ecdh
rsa_fixed_dh
dh_fixed_dh,

although it supports ECDH_ECDSA and ECDH_RSA (if I remember correctly)

so your point is moot. Anyway, the only client implementations we found
that were actually vulnerable to the attack (Safari/Mac OS X --
supporting (EC)DH_* key exchange and *fixed_(ec)dh client
authentication) did not make these assumption you are talking about, and
I can not see why they should.

We are currently working on  a video showcasing an actual attack (Safari
-- Facebook).


> 
>>> NSS (incorrectly) adopts the posture that _ECDH_ suites are
>>> half-static: the server share is in the certificate, but the client
>>> side is fully ephemeral.  This is clearly in violation of RFC 5246,
>>> Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about
>>> that right now :)
>>
>> Please elaborate. I do not see how this half-static behaviour
>> constitutes any violations of the mentioned RFCs.
> 
> Both the above cited sections say very clearly that for fixed (EC)DH
> cipher suites the client where the client has a fixed (EC)DH
> certificate, the client MUST send an empty ClientKeyExchange.


Yes, that is correct. But for fixed (EC)DH client authentication.


> 
> Of course, you might say that this is simply a consequence of not
> supporting fixed (EC)DH for client authentication, and then it's not
> technically in violation.  The value of the ClientCertificateType from
> the CertificateRequest is likely important here, but that field is
> systematically ignored in practice (NSS ignores it).


I could find nowhere in the spec that a (non-ephemeral)
 (EC)DH key agreement necessary implies fixed (EC)DH client
authentication to be used. The other direction (fixed (EC)DH client
authentication requires a (EC)DH key agreement, is insinuated by the
spec, but still left ambiguous (a conclusion I came to after discussing
exactly that with the OpenSSL developers).

Regards,
Clemens




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

Re: [TLS] TLS and KCI vulnerable handshakes

[Clemens Hlauschek]

On 08/11/2015 02:05 PM, Peter Gutmann wrote:
> Clemens Hlauschek  writes:
> 
>> I published a paper today on KCI-attacks in TLS. This might be of interest to
>> the TLS WG.
>>
>> https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek
> 
> Some comments on this, it looks like it requires a "cert with static (EC)DH
> key" in order to work, which would mean an X9.42 cert.  Since no (public) CA
> that I know of can handle or issue such certs, this probably provides a
> reasonable amount of defence against this attack...



Thanks for the critical reading. Actually, your point is touched upon in
the paper. Instead of an ECDH certificate, an ECDSA certificate can be
used by the attacker. The case for DH/DSS is different, and your point
is valid for this latter case. I am working on a video showcasing the
attack (Safari <-> Facebook), but if you decide that you still would not
trust our claims made in the paper, it would be trivial to reproduce the
attack: our MitM proof-of-concept implementation was realized with less
than 10 patched lines of the openssl/stunnel codebase.


See also RFC 4492:
"Note that there is no structural difference between ECDH and ECDSA
keys.  A certificate issuer may use X.509 v3 keyUsage and
extendedKeyUsage extensions to restrict the use of an ECC public key
to certain computations"

> 
> In terms of the suggested countermeasures:
> 
>> Set appropriate X509 Key Usage extension for ECDSA and DSS certificates, and
>> disable specifically the KeyAgreement flag
> 
> Since the keyUsage flags are widely ignored by implementations, this won't
> provide the protection that the text implies.
> 


In case of the vulnerable Safari / SecureTransport / Mac OS X clients,
it does make a difference, so having correct X509 KeyUsage settings is
the best (and only sensible for servers supporting ECDSA) recommendation
for server-side mitigation, from our perspective. The facebook.com
security teams very quickly implemented that change. While it is
certainly true that keyUsage flags are ignored by many implementations
(this is also mentioned in the paper), checking (it is ambiguous
according to the TLS specs whether it is mandatory for ECDH, but it is
mandatory for DH if the KeyUsage extension is present) seems to have
become more widespread recently.


Best,
Clemens

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Peter Gutmann]

Ilari Liusvaara  writes:

>a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is no
>ECDSA-specific keytype in X.509.

That's always concerned me about ECC certs, all you can say about a key is
"ECC", not "signing key" or "key agreement key" (I'm sure this was seen as a
great feature when the key format was designed, "ECC is so much more flexible
than RSA, you can use it for anything!").  My code explicitly ACLs ECC keys
coming from certs to be signing-only in order to deal with this problem.

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