On Sunday 12 July 2015 16:39:37 Simon Josefsson wrote:
> Hubert Kario writes:
> > As is described in secion 5.1. of RFC 4492, and then reiterated in
> > section 2.2. of this draft - the elliptic_curves (a.k.a. supported_groups)
> > guides both the ECDH curves and curves understandable by peer for
On Saturday 11 July 2015 17:09:27 Dave Garrett wrote:
> On Saturday, July 11, 2015 04:48:10 pm Viktor Dukhovni wrote:
> > Largely close enough. Feel free to borrow any text from the below
> > that you find to be an improvement.
> >
> >
> >
> >
Viktor Dukhovni wrote:
> Andrei Popov wrote:
>>
>> When old algorithms are deprecated and new algorithms replace them in
>> actual deployments (a very slow process), an opportunistic client would
>> need to be updated, just like a normal server-authenticating client does.
>> Except for the opportu
Hubert Kario writes:
> On Sunday 12 July 2015 16:39:37 Simon Josefsson wrote:
>> Hubert Kario writes:
>> > As is described in secion 5.1. of RFC 4492, and then reiterated in
>> > section 2.2. of this draft - the elliptic_curves (a.k.a. supported_groups)
>> > guides both the ECDH curves and curve
On Tue, Jul 14, 2015 at 11:31:26AM +0200, Hubert Kario wrote:
> >
> > All certificates provided by the server SHOULD be signed by a
> > hash/signature algorithm pair indicated by the client's
> > "signature_algorithms" extension (or the defaults assumed in
On Tue, Jul 14, 2015 at 05:23:44PM +0200, Simon Josefsson wrote:
> Hubert Kario writes:
>
> > So unless the PKIX and TLS parts are defined at the same time, in the same
> > document, we definitely need to keep them apart.
>
> It is conceivable to reuse the NamedCurve values for TLS authenticati
On Tue, Jul 14, 2015 at 03:46:12PM +0200, Martin Rex wrote:
[ There's no need to belabour the obvious, yes unauthenticated TLS
does not protect against active attacks, absent authenticated
channel binding post handshake. This does not mean that the are
no appropriate use-cases for anon_DH a
Using anonymous cipher suites for opportunistic connections allows the server
operator to explicitly enable anonymous connections, and it saves bytes on the
wire.
The downside is of course that the attacker can easily distinguish
opportunistic clients from server-authenticating ones. Is this a
On 14 July 2015 at 12:30, Andrei Popov wrote:
> The downside is of course that the attacker can easily distinguish
> opportunistic clients from server-authenticating ones. Is this a concern for
> the opportunistic TLS community?
I raised the concern about this previously. Opportunistic MitM
ha
If opportunistic TLS handshakes need to be indistinguishable from
server-authenticated TLS handshakes, then perhaps opportunistic clients have no
choice but to send the signature_algorithms extension (when offering TLS1.2).
The absence of signature_algorithms in a TLS 1.2 ClientHello can be used
On Tue, Jul 14, 2015 at 07:30:38PM +, Andrei Popov wrote:
> Using anonymous cipher suites for opportunistic connections allows the
> server operator to explicitly enable anonymous connections, and it saves
> bytes on the wire.
Yes, and informs the server that the client is skipping authentica
On Tue, Jul 14, 2015 at 08:06:19PM +, Andrei Popov wrote:
> If opportunistic TLS handshakes need to be indistinguishable from
> server-authenticated TLS handshakes, then perhaps opportunistic clients
> have no choice but to send the signature_algorithms extension (when offering
> TLS1.2). The
On 14 July 2015 at 13:08, Viktor Dukhovni wrote:
> Yes, and informs the server that the client is skipping authentication,
> which is often useful information on the server end.
The problem here is that the server isn't the only recipient of that signal.
_
On Tue, Jul 14, 2015 at 01:49:36PM -0700, Martin Thomson wrote:
> On 14 July 2015 at 13:08, Viktor Dukhovni wrote:
> > Yes, and informs the server that the client is skipping authentication,
> > which is often useful information on the server end.
>
> The problem here is that the server isn't th
14 matches
Mail list logo
