Re: [TLS] Empty CertificateRequest.supported_signature_algorithms in TLS 1.2
On Thu, Nov 22, 2018 at 9:08 AM David Benjamin wrote: > Maybe we should errata this by fixing that <2^16-1> to <2..2^16-1>? https://www.rfc-editor.org/errata/eid2864 was filed a while ago. Apparently also erratum 1585 found an error. We really need a view of these documents that includes errata. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Empty CertificateRequest.supported_signature_algorithms in TLS 1.2
On Wed, Nov 21, 2018 at 3:50 PM Martin Thomson
wrote:
> In attempting to fix a bug related to this, a question came up about
> what the semantics of an empty value is here. Some implementations
> seem to infer that empty means {*,SHA1}, which effectively assumes
> that an empty value is equivalent to an absent signature_algorithms
> extension (Section 7.4.1.4.1)
>
In the ClientHello, I believe an empty signature_algorithms extension is
invalid. The structure is defined as:
SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>;
BoringSSL enforces this. If your ClientHello has an empty
signature_algorithms extension, we will reject it. If it is missing, we do
interpret it as {*, SHA1}, as TLS 1.2 (mistakenly) prescribes.
> The text on CertificateRequest is less clear about what to do. That's
> understandable because it doesn't have to deal with the value being
> absent because it's not optional. All we have to go on is this from
> Section 7.4.8:
>
>The hash and signature algorithms used in the signature MUST be
>one of those present in the supported_signature_algorithms field
>of the CertificateRequest message.
>
> We think that treating an empty supported_signature_algorithms field
> as an error is the best response and plan to implement that change.
> We'll send a fatal alert if we receive one.
>
> This is consistent with our handling of the signature_algorithms
> extension, where we treat an empty list as a failure.
>
Sadly, the structure itself has a syntax error, so it's unclear whether
empty is allowed or not. :-)
struct {
ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2^16-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
We do tolerate empty and give it the same {*, SHA1} interpretation as
ClientHello, since they go through the same logic, but I agree with you
that the specification does not actually say it applies to both. Rejecting
the empty list sounds like a good idea, assuming it's compatible with
current implementations. The 7.4.8 citation looks right, and rejecting it
makes sense on general principle. IMO, the default {*, SHA1} bit in TLS 1.2
was a mistake. It's caused unnecessary confusion, resulting in buggy TLS
1.2 servers that only sign SHA-1.
Maybe we should errata this by fixing that <2^16-1> to <2..2^16-1>?
David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Empty CertificateRequest.supported_signature_algorithms in TLS 1.2
On Wed, Nov 21, 2018 at 1:50 PM Martin Thomson
wrote:
> In attempting to fix a bug related to this, a question came up about
> what the semantics of an empty value is here. Some implementations
> seem to infer that empty means {*,SHA1}, which effectively assumes
> that an empty value is equivalent to an absent signature_algorithms
> extension (Section 7.4.1.4.1)
>
> The text on CertificateRequest is less clear about what to do. That's
> understandable because it doesn't have to deal with the value being
> absent because it's not optional. All we have to go on is this from
> Section 7.4.8:
>
>The hash and signature algorithms used in the signature MUST be
>one of those present in the supported_signature_algorithms field
>of the CertificateRequest message.
>
> We think that treating an empty supported_signature_algorithms field
> as an error is the best response and plan to implement that change.
> We'll send a fatal alert if we receive one.
>
Yes, I believe this is the right approach.
-Ekr
> This is consistent with our handling of the signature_algorithms
> extension, where we treat an empty list as a failure.
>
> ___
> 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] Empty CertificateRequest.supported_signature_algorithms in TLS 1.2
> On Nov 21, 2018, at 4:50 PM, Martin Thomson wrote:
>
> In attempting to fix a bug related to this, a question came up about
> what the semantics of an empty value is here. Some implementations
> seem to infer that empty means {*,SHA1}, which effectively assumes
> that an empty value is equivalent to an absent signature_algorithms
> extension (Section 7.4.1.4.1)
>
> [...]
>
> We think that treating an empty supported_signature_algorithms field
> as an error is the best response and plan to implement that change.
> We'll send a fatal alert if we receive one.
Sounds reasonable, provided the application did or would have actually
provided a client certificate to use. If the application would have
continued with an empty certificate list, and no CertificateVerify,
then hanging up is arguably counter-productive. Of course the server
should still not send a certificate request that could never be satisfied,
so perhaps snatching victory from the jaws of defeat is not worth the
trouble even when the client has no certificate to send?
--
Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Empty CertificateRequest.supported_signature_algorithms in TLS 1.2
In attempting to fix a bug related to this, a question came up about
what the semantics of an empty value is here. Some implementations
seem to infer that empty means {*,SHA1}, which effectively assumes
that an empty value is equivalent to an absent signature_algorithms
extension (Section 7.4.1.4.1)
The text on CertificateRequest is less clear about what to do. That's
understandable because it doesn't have to deal with the value being
absent because it's not optional. All we have to go on is this from
Section 7.4.8:
The hash and signature algorithms used in the signature MUST be
one of those present in the supported_signature_algorithms field
of the CertificateRequest message.
We think that treating an empty supported_signature_algorithms field
as an error is the best response and plan to implement that change.
We'll send a fatal alert if we receive one.
This is consistent with our handling of the signature_algorithms
extension, where we treat an empty list as a failure.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNIKeys over complex
On Tue, Nov 20, 2018 at 11:28 PM Paul Wouters wrote: > Although, if I am correct, the epectation is that all of this data > will be used without mandating DNSSEC validation, so all these > security parameters could be modified by any DNS party in transit > to try and break the protocol or privacy of the user. > Yes, because being able to modify the A/ records is generally sufficient to determine the SNI. See: https://tools.ietf.org/html/draft-ietf-tls-esni-02#section-7.1 -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNIKeys over complex
* Paul Wouters: > On Wed, 21 Nov 2018, Stephen Farrell wrote: > >>> We currently permit >1 RR, but >>> actually >>> I suspect that it would be better to try to restrict this. >> >> Not sure we can and I suspect that'd raise DNS-folks' hackles, >> but maybe I'm wrong. > > I think the SOA record is the only exception allowed (and there > is an exception to that when doing AXFR I believe) > > Usually these things are defined as "pick the first DNS RRTYPE > that satisfies you". Not sure what you mean by that (RRTYPE?). The DNAME algorithm (RFC 6672) only works if there is a single DNAME record for an owner name. RFC 1034 is also pretty clear that only CNAME record is permitted per owner name. To be honest, I don't expect much opposition from DNS people, as long as there is no expectation that the DNS layer is expected to reject multiple records. If the higher-level protocol treats non-singleton RRsets as a hard error, I expect that would be fine. DNS treats RRsets as an atomic unit, so there is no risk here that a zone file change ends up producing a multi-record RRset due to caching. Thanks, Florian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
