Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote: > > > On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide < > viktor.s.wold.e...@gmail.com> wrote: > >> Hi, >> >> I am looking for a way to achieve identity hiding for DTLS 1.2, which >> also hopefully can be used in (D)TLS 1.3, when available. >> >> From what I understand, for (D)TLS 1.2 it would be possible to perform an >> anonymous unencrypted handshake and then to renegotiate the connection with >> authentication within the encrypted channel, e.g., according to the expired >> draft [1]. From the latest TLS 1.3 draft [2] it appears that renegotiation >> will be removed in the upcoming 1.3 version. >> >> What is likely to be the recommended way to achieve identity hiding for >> (D)TLS 1.3, if any? >> >> [1] Transport Layer Security (TLS) Encrypted Handshake Extension, >> draft-ray-tls-encrypted-handshake-00, expired in 2012 >> [2] The Transport Layer Security (TLS) Protocol Version 1.3, >> draft-ietf-tls-tls13-07 >> >> > TLS 1.3 encrypts both the client's and server's certificates already. > The server's certificate is secure only against passive attack. The > client's is encrypted with a key that the client can authenticate as > belonging to the server. > > Thanks a lot for the clarification. Would it be reasonable to include your answer or something similar into the TLS 1.3 draft, for example in the "Major Differences from TLS 1.2" section? Best regards Viktor S. Wold Eide ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Tue, Aug 25, 2015 at 12:19 AM, Badra wrote: > Hi, > > Another solution was approved for publication as experimental by IESG in > 2009 but I declined to process with Pasi Eronen way (previous WG co-Chair) > of publishing the document. > > It is available at > https://tools.ietf.org/html/draft-hajjeh-tls-identity-protection-09 and > it works for TLS and DTLS > > Thanks for the reference. Best regards Viktor S. Wold Eide ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Tue, Aug 25, 2015 at 10:43 AM, Pascal Urien wrote: > Hi > > a working solution fot TLS 1.0,1.1, 1.2, DTLS 1.0, 1.2 is to encrypt > the client certificat with an extra key computed from the master > secret > > see > > https://tools.ietf.org/html/draft-urien-badra-eap-tls-identity-protection-01 > > Thanks for the suggestion and for the reference. Best regards Viktor S. Wold Eide ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote: > > > TLS 1.3 encrypts both the client's and server's certificates already. > The server's certificate is secure only against passive attack. The > client's is encrypted with a key that the client can authenticate as > belonging to the server. > > It's good to see that both the client's and the server's certificates are encrypted in TLS 1.3, providing protection against passive eavesdropping. For some use cases it might be worthwhile to reduce the information made available to an active attacker also. Are there any suggestions in this direction for TLS 1.3? One might think of a multi stage approach, something like: - Anonymous connection establishment, resulting in a secure channel. - Authentication by means of group certificate. - Authentication by means of a host specific certificate. The purpose of the second step above is to first only provide the group identity to an active attacker, and then to reveal the host identities (certificate information) only after group membership has been mutually authenticated. Does something like this seem reasonable for TLS 1.3 or are there any other ways for providing protection of identities against an active attack? Best regards Viktor S. Wold Eide ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Thu, Aug 27, 2015 at 1:37 AM, Viktor S. Wold Eide < viktor.s.wold.e...@gmail.com> wrote: > > On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote: > >> >> >> On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide < >> viktor.s.wold.e...@gmail.com> wrote: >> >>> Hi, >>> >>> I am looking for a way to achieve identity hiding for DTLS 1.2, which >>> also hopefully can be used in (D)TLS 1.3, when available. >>> >>> From what I understand, for (D)TLS 1.2 it would be possible to perform >>> an anonymous unencrypted handshake and then to renegotiate the connection >>> with authentication within the encrypted channel, e.g., according to the >>> expired draft [1]. From the latest TLS 1.3 draft [2] it appears that >>> renegotiation will be removed in the upcoming 1.3 version. >>> >>> What is likely to be the recommended way to achieve identity hiding for >>> (D)TLS 1.3, if any? >>> >>> [1] Transport Layer Security (TLS) Encrypted Handshake Extension, >>> draft-ray-tls-encrypted-handshake-00, expired in 2012 >>> [2] The Transport Layer Security (TLS) Protocol Version 1.3, >>> draft-ietf-tls-tls13-07 >>> >>> >> TLS 1.3 encrypts both the client's and server's certificates already. >> The server's certificate is secure only against passive attack. The >> client's is encrypted with a key that the client can authenticate as >> belonging to the server. >> >> > Thanks a lot for the clarification. > > Would it be reasonable to include your answer or something similar into > the TLS 1.3 draft, for example in the "Major Differences from TLS 1.2" > section? > Sure. It's mostly a changelog now, but I'll try to add something. -Ekr > Best regards > Viktor S. Wold Eide > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide < viktor.s.wold.e...@gmail.com> wrote: > On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote: > >> >> >> TLS 1.3 encrypts both the client's and server's certificates already. >> The server's certificate is secure only against passive attack. The >> client's is encrypted with a key that the client can authenticate as >> belonging to the server. >> >> > > It's good to see that both the client's and the server's certificates are > encrypted in TLS 1.3, providing protection against passive eavesdropping. > > For some use cases it might be worthwhile to reduce the information made > available to an active attacker also. Are there any suggestions in this > direction for TLS 1.3? > > One might think of a multi stage approach, something like: > - Anonymous connection establishment, resulting in a secure channel. > - Authentication by means of group certificate. > - Authentication by means of a host specific certificate. > > The purpose of the second step above is to first only provide the group > identity to an active attacker, and then to reveal the host identities > (certificate information) only after group membership has been mutually > authenticated > I don't think this matches most TLS use cases very well, since the client generally isn't authenticated at all, so there's no point in the server progressively revealing more. -Ekr Does something like this seem reasonable for TLS 1.3 or are there any other > ways for providing protection of identities against an active attack? > > Best regards > Viktor S. Wold Eide > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus on PR 169 - relax certificate list requirements
To me it seems that both of these wordings could be interpreted by someone that if you do not have a trust anchor and you get it in the TLS handshake, you can use it and trust it. That sounds dangerous. -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett Sent: Wednesday, August 26, 2015 5:42 PM To: tls@ietf.org Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements On Wednesday, August 26, 2015 05:11:01 pm Joseph Salowey wrote: > It looks like we have good consensus on PR 169 to relax certificate > list ordering requirements. I had one question on the revised text. > I'm unclear on the final clause in this section: > > "Because certificate validation requires that trust anchors be > distributed independently, a self-signed certificate that specifies a > trust anchor MAY be omitted from the chain, provided that supported > peers are known to possess any omitted certificates they may require." > > I just want to make sure there isn't the intention of omitting > certificates that are not seif-signed. Well, technically anything can be omitted; it just won't validate. :p I'm not opposed to tweaking the wording here, but I don't really see it as a problem. If someone does, though, that's reason enough for me to agree to changing it. Simplest change is: "any omitted certificates they may require" -> "it" \/ "Because certificate validation requires that trust anchors be distributed independently, a self-signed certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess it." Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus on PR 169 - relax certificate list requirements
On Thu, Aug 27, 2015 at 01:22:33PM -0400, Santosh Chokhani wrote: > To me it seems that both of these wordings could be interpreted by someone > that if you do not have a trust anchor and you get it in the TLS handshake, > you can use it and trust it. > > That sounds dangerous. Beyond a general "there's no such thing as fool-proof", I don't see how such an interpretation might be arrived at. Trust-anchors are both frequently sent and frequently not sent in the TLS handshake. The new text just says that it may be acceptable to omit them, but sometimes clients need the trust-anchor certificate to be sent, because they verify it by fingerprint or similar, and don't have a (complete) local copy. The text is fine. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] MUST or what?
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}}).
> All implementations MUST use the "signature_algorithms" extension when
offering and negotiating certificate authenticated cipher suites.
> All implementations MUST use the "supported_groups" extension when
offering and negotiating DHE or ECDHE cipher suites.
This isn't good. "MUST" language MUST have consequences or you are
left with all sorts of variations. If you don't stipulate
consequences, then people violate the MUST and you get interop issues.
I propose that we don't do this in future without due consideration.
In all these cases, the peer that notices a violation of the
requirement can (and I would argue MUST) fail the handshake and
probably generate a fatal alert.
The exceptions to this are where you need to permit non-compliant
behaviour for legacy interoperability reasons. For TLS 1.3, I think
that we can limit that to the ClientHello handling and - if we feel
like we can mandate changes that affect TLS 1.2 or earlier for clients
that support 1.3 - the ServerHello. I think only the ClientHello.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
On Thu, Aug 27, 2015 at 11:48 AM, 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}}).
>
I note that we had a very extensive discussio n
> > All implementations MUST use the "signature_algorithms" extension when
> offering and negotiating certificate authenticated cipher suites.
>
> > All implementations MUST use the "supported_groups" extension when
> offering and negotiating DHE or ECDHE cipher suites.
>
This is an example of a MUST that is not always easy to enforce. Consider
what happens if you have a client which offers both ECDHE and PSK
(for resumption) and omits supported_groups. If the server picks
PSK it's a pain to check for supported groups and I'm not sure that
the world is improved by that code.
> I propose that we don't do this in future without due consideration.
> In all these cases, the peer that notices a violation of the
> requirement can (and I would argue MUST) fail the handshake and
> probably generate a fatal alert.
>
I agree consideration of this question is good.
The exceptions to this are where you need to permit non-compliant
> behaviour for legacy interoperability reasons. For TLS 1.3, I think
> that we can limit that to the ClientHello handling and - if we feel
> like we can mandate changes that affect TLS 1.2 or earlier for clients
> that support 1.3 - the ServerHello. I think only the ClientHello.
As noted above, I don't think that this is the only exception.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
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)
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett
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
Re: [TLS] MUST or what?
On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote: > 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. I'm not fundamentally opposed to having a hard requirement of an error check on negotiation, and basically a soft expectation on mere offering (SHOULD, MAY, or not mentioned; stern warning and shake of finger). That said, categorizing the cipher suites and just doing a quick check for which categories are there and what extensions came with it is not a very complicated requirement. I'm philosophically in the "do it right or explode so it can be found and fixed immediately" camp when it comes to very clear requirements like this, but I'm aware that this is sadly not always the dominant thought process. :| Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
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" wrote:
>
>
> On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett
> 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
Re: [TLS] MUST or what?
On Thu, Aug 27, 2015 at 12:26:03PM -0700, Eric Rescorla wrote: > 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. One issue related to "layered" negotiation, in which one first chooses X, then with X already chosen, chooses Y, ... is that some choices of X are not compatible with any available Y, while other choices of X might work. A specific example may help: Many libraries will first choose the highest mutually supported protocol version, and only then select a mutually supported cipher suite. However, not all ciphersuites are compatible with all protocols versions. So we can have situations in which TLS 1.2 and TLS 1.3 are offered by the client and TLS 1.3 is selected by the server, but none of the ciphers offered by the client are AEAD. Should the server have chosen TLS 1.2, or MUST the client figure out that it can't do TLS 1.3 and not offer it. There will undoubtedly be clients that naively give the server "impossible" options along with other options that work. Should servers try to handle this gracefully? Note that in the above scenario the client might offer *some* TLS 1.3 compatible ciphers, but it may happen that none are shared by the server, while they both share common TLS 1.2 ciphers. One way to avoid such problems is to suggest that clients that don't offer the MTI ciphers for a particular protocol version (and thus can't generically expect interoperability with servers that implement that protocol) SHOULD NOT offer the protocol version. Libraries might then have an option that is on by default, and suppresses protocols for which the MTI ciphers are not enabled. Clients that really want to offer only non-MTI ciphers would have to clear the option explicitly. Half-baked ideas aside, some discussion of the problem may be relevant so that servers or clients avoid negotiating impossible partial choices. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
The statement I'd like to see is something like this... An endpoint that receives an illegal combination of "things" MAY choose to treat that as a fatal error. In this case, that means that if you include an ECDHE suite without an ECDHE named_group, don't expect to have the connection succeed. On Aug 27, 2015 12:51 PM, "Dave Garrett" wrote: > On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote: > > 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. > > I'm not fundamentally opposed to having a hard requirement of an error > check on negotiation, and basically a soft expectation on mere offering > (SHOULD, MAY, or not mentioned; stern warning and shake of finger). That > said, categorizing the cipher suites and just doing a quick check for which > categories are there and what extensions came with it is not a very > complicated requirement. I'm philosophically in the "do it right or explode > so it can be found and fixed immediately" camp when it comes to very clear > requirements like this, but I'm aware that this is sadly not always the > dominant thought process. :| > > > Dave > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
On Thu, Aug 27, 2015 at 1:01 PM, Martin Thomson
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" wrote:
>
>>
>>
>> On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett
>> 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
Re: [TLS] MUST or what?
On Thu, Aug 27, 2015 at 1:06 PM, Martin Thomson wrote: > The statement I'd like to see is something like this... > > An endpoint that receives an illegal combination of "things" MAY choose to > treat that as a fatal error. > This seems totally reasonable. -Ekr > In this case, that means that if you include an ECDHE suite without an > ECDHE named_group, don't expect to have the connection succeed. > On Aug 27, 2015 12:51 PM, "Dave Garrett" wrote: > >> On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote: >> > 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. >> >> I'm not fundamentally opposed to having a hard requirement of an error >> check on negotiation, and basically a soft expectation on mere offering >> (SHOULD, MAY, or not mentioned; stern warning and shake of finger). That >> said, categorizing the cipher suites and just doing a quick check for which >> categories are there and what extensions came with it is not a very >> complicated requirement. I'm philosophically in the "do it right or explode >> so it can be found and fixed immediately" camp when it comes to very clear >> requirements like this, but I'm aware that this is sadly not always the >> dominant thought process. :| >> >> >> Dave >> > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
> An endpoint that receives an illegal combination of "things" MAY choose to > treat that as a fatal error. >From the guy who wrote that Postel was wrong. But +1 from me. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
PR to put this into writing: https://github.com/tlswg/tls13-spec/pull/232 Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
Martin Thomson writes: >An endpoint that receives an illegal combination of "things" MAY choose to >treat that as a fatal error. Does that actually help? What it's saying in full is: An endpoint that receives an illegal combination of "things" MAY choose to treat that as a fatal error or MAY choose not to treat it as a fatal error. which is a no-op. Admittedly it explicitly allows you to treat it as an error while previously the response was left open, but it's still not terribly useful, anyone writing a client that submits gibberish things can claim it's OK and the server needs to be fixed to accept it. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
Martin Thomson writes: >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. I have to do the same thing, bouncing back and forth between cipher suites and extensions in order to find something that fits. That was the motivation for the creation of the "Standardised ECC Cipher Suites for TLS" draft: TLS-ECC [3] provides an extremely flexible, and by extension extremely complex means of specifying a large number of options involving the use of ECC algorithms for TLS [2]. As such the "cipher suites" in TLS-ECC [3] and by extension TLS-ECC-Brainpool [4] aren't suites in the conventional TLS sense but more an indication of intent to negotiate a Chinese menu, with details to be decided on later via various TLS extensions and parameter settings. This makes deciding on a particular suite nondeterministic, since later parameter choices and settings can negate the initial "cipher suite" choice, requiring returning to the suite list to try with another Chinese-menu suite in the hope that later parameter choices allow it to be used. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
