On Thu, Aug 27, 2015 at 1:01 PM, Martin Thomson <martin.thom...@gmail.com>
wrote:
> The opposite in fact. NSS checks extensions first. That is how we filter
> out ECC cipher suites if the named_groups extension doesn't list anything
> we support.
>
Well, yes and no. We don't for instance check for the *absence* of the
extension.
-Ekr
> On Aug 27, 2015 12:26 PM, "Eric Rescorla" <e...@rtfm.com> wrote:
>
>>
>>
>> On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett <davemgarr...@gmail.com>
>> wrote:
>>
>>> On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote:
>>> > I've been looking at the latest TLS 1.3 spec and there are a lot of
>>> > MUSTs that are completely toothless. To pick on a recent changeset:
>>> >
>>> > > The signature algorithm and hash algorithm MUST be a pair offered in
>>> the
>>> > "signature_algorithms" extension (see {{signature-algorithms}}).
>>>
>>> Some changes to this are now in this PR:
>>> https://github.com/tlswg/tls13-spec/pull/231/files
>>> (language based on list discussion)
>>>
>>> > > All implementations MUST use the "signature_algorithms" extension
>>> when
>>> > offering and negotiating certificate authenticated cipher suites.
>>>
>>> Actually, I did get a strict requirement in there for that one:
>>>
>>>
>>> https://github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.md#signature-algorithms
>>> > All clients MUST send a valid "signature_algorithms" extension in
>>> their ClientHello when offering certificate authenticated cipher suites.
>>> Servers receiving a TLS 1.3 ClientHello offering certificate authenticated
>>> cipher suites without this extension MUST send a "missing_extension" alert
>>> message and close the connection.
>>>
>>> I think it warrants repeating in the MTI section as well.
>>>
>>> > > All implementations MUST use the "supported_groups" extension when
>>> > offering and negotiating DHE or ECDHE cipher suites.
>>>
>>> My initial draft had similar language, however ekr says the WG doesn't
>>> have consensus to be more strict. I would like to consider all of these
>>> extensions as mandatory to send, and malformed if not present when
>>> offering/negotiating any applicable cipher suites:
>>> signature_algorithms, supported_groups, client_key_share,
>>> pre_shared_key, server_name (though, I'm fine with a SHOULD error on lack
>>> of SNI when applicable
>>
>>
>> My problem is precisely the conflation of offering with negotiating. The
>> way that
>> many stacks work (for instance NSS) is that they negotiate the cipher
>> suite
>> *first* and then they check for the presence or absence of the relevant
>> extensions.
>> It's not clear to me that it's an improvement to require them to check
>> for error
>> conditions that are not otherwise relevant.
>>
>> -Ekr
>>
>>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
