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
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 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
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
> 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
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
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
> 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
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
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 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
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
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
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.
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
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
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 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
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
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 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
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
22 matches
Mail list logo
