Re: [TLS] MUST <x> or what?

[Martin Thomson <[e-mail]>]

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.
On Aug 27, 2015 12:26 PM, "Eric Rescorla" <[e-mail]> wrote:

>
>
> On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett <[e-mail]>
> 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
>
>