Andrei Popov wrote:
> I'm not happy with this either.
I liked that proposal.
The spec already says:
>
> "If the client supports only the default hash and signature algorithms
> (listed in this section), it MAY omit the signature_algorithms
> extension. If the client does not support the defau
On Fri, Jul 10, 2015 at 4:29 PM, Martin Rex wrote:
> Henrik Grubbström wrote:
>> Martin Rex wrote:
>>> The issue here is the (lack of the) TLSv1.2 signature_algorithms extension.
>>>
>>> Windows SChannel appears to treat the absence of this extension
>>> the same as the presence of an extension
Henrik Grubbström wrote:
> Martin Rex wrote:
>>
>> Nope, _our_ client is perfectly compliant by _not_ sending TLS extensions.
>> SCHannel is violating a MUST requirement, failing to properly process
>> a ServerHello without a TLS extension.
>>
>> https://tools.ietf.org/html/rfc5246#section-7.4.1.2
On Mon, Jul 13, 2015 at 04:30:06PM +0200, Martin Rex wrote:
> Section 7.4.1.4 Hello Extensions and its subsections are clearly IRRELEVANT
> for a client that does not use Hello Extensions.
Let's not go back to lawyering the RFCs. We've been there already,
with not much success. I think we can r
On Monday, July 13, 2015 10:30:06 am Martin Rex wrote:
> Section 7.4.1.4 Hello Extensions and its subsections are clearly IRRELEVANT
> for a client that does not use Hello Extensions.
If you want to put it that way, sure, however they are NOT irrelevant for a
_server_ that does use hello extensio
Dave Garrett wrote:
> On Monday, July 13, 2015 10:30:06 am Martin Rex wrote:
>> Section 7.4.1.4 Hello Extensions and its subsections are clearly
>> IRRELEVANT for a client that does not use Hello Extensions.
>
> If you want to put it that way, sure, however they are NOT irrelevant
> for a _server_
On Mon, Jul 13, 2015 at 06:10:52PM +0200, Martin Rex wrote:
> Dave Garrett wrote:
> > On Monday, July 13, 2015 10:30:06 am Martin Rex wrote:
> >> Section 7.4.1.4 Hello Extensions and its subsections are clearly
> >> IRRELEVANT for a client that does not use Hello Extensions.
> >
> > If you want to
On Mon, Jul 13, 2015 at 9:28 AM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Mon, Jul 13, 2015 at 06:10:52PM +0200, Martin Rex wrote:
> > Dave Garrett wrote:
> > > On Monday, July 13, 2015 10:30:06 am Martin Rex wrote:
> > >> Section 7.4.1.4 Hello Extensions and its subsections are
Ilari Liusvaara wrote:
>
> E.g. if client advertised {sha256, ecdsa} + in its
> signature_algorithms and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> + others in its ciphersuites, then the server MAY pick
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and then proceed to
> sign the handshake with ECDSA/SHA-256.
I think a good design is to have the client explicitly advertise any algorithms
the client is willing/able to support, and for the server to honor the client's
capabilities.
IMHO the existing specs already meet the above goal, with an unfortunate quirk
that SHA1/MD5-only clients don't have to b
Andrei Popov wrote:
>
> I think a good design is to have the client explicitly advertise any
> algorithms the client is willing/able to support, and for the server
> to honor the client's capabilities.
A good design provides robust interop and good backwards-interoperability,
and a reasonble defau
On Mon, Jul 13, 2015 at 05:11:29PM +, Andrei Popov wrote:
> I think a good design is to have the client explicitly advertise any
> algorithms the client is willing/able to support, and for the server to
> honor the client's capabilities.
To the extent possible. However, the server SHOULD NOT
To keep it short, +1 to Viktor’s point.
--
Regards,
Uri Blumenthal
On 7/13/15, 14:01 , "TLS on behalf of Viktor Dukhovni"
wrote:
>On Mon, Jul 13, 2015 at 05:11:29PM +, Andrei Popov wrote:
>
>> I think a good design is to have the client explicitly advertise any
>> algorithms the client
On Monday, July 13, 2015 01:11:29 pm Andrei Popov wrote:
> My preference would be to keep the client explicitly advertising its
> capabilities, and the server strictly honoring the client-advertised
> capabilities. And since the concept of "default algorithms" confuses people,
> let's just get r
> An opportunistic TLS or DANE TLSA client cannot advertise the capability of
> supporting algorithms it was aware existed (by ignoring all signatures in the
> chain).
> We surely don't want to muddy the waters by adding "wildcard" algorithm
> code-points, and new APIs for clients to request tha
Eric Rescorla wrote:
> I'm not necessarily opposed to relaxing this requirement on the server,
> but given that:
>
> 1. SHA-1 is on its way out.
> 2. Future versions of TLS seem very likely to explicitly indicate which
> hash algorithms the clients support.
>
> I'm kind of confused about the prin
On Mon, Jul 13, 2015 at 07:45:30PM +, Andrei Popov wrote:
> Would it make sense for an opportunistic client to advertise all algorithms
> commonly supported in the server certs? After all, there are relatively
> few signature/hash pairs in use, and they are changing very slowly over
> time.
T
> This does not work when new algorithms are introduced, since you can't
> advertise algorithms you don't know exist.
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 norm
Viktor Dukhovni wrote:
> Andrei Popov wrote:
>>
>> Would it make sense for an opportunistic client to advertise all algorithms
>> commonly supported in the server certs? After all, there are relatively
>> few signature/hash pairs in use, and they are changing very slowly over
>> time.
>
> This do
On Mon, Jul 13, 2015 at 10:31:16PM +, 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 t
On Monday, July 13, 2015 10:47:11 pm Viktor Dukhovni wrote:
> Furthermore, DANE-EE(3) clients and certificate pinning clients
> cannot use anon_DH, they still a recognizable certificate from the
> server, they just often don't need a recognizable signature. Even
> DANE-TA(2) clients might be able
On Tue, Jul 14, 2015 at 12:38:51AM -0400, Dave Garrett wrote:
> > Furthermore, DANE-EE(3) clients and certificate pinning clients
> > cannot use anon_DH, they still a recognizable certificate from the
> > server, they just often don't need a recognizable signature. Even
> > DANE-TA(2) clients mig
22 matches
Mail list logo
