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 t
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
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 connectio
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 s
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 “conf
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/mail
-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 w
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 w
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 ho
>> 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 p
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) b
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
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) beca
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.
>>
>>
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 differ
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. Thi
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 conf
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
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 featur
19 matches
Mail list logo
