On Tue, May 23, 2017 at 5:17 AM, Nico Williams <n...@cryptonector.com> wrote:
> On Tue, May 23, 2017 at 04:42:45AM +0900, Eric Rescorla wrote: > > Well, I certainly think past the Web PKI, because one of the cases I > > care about is WebRTC, which doesn't do any PKI validation at all. > > > > In any case, I think there are two issues: > > 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1. > > 2. Require a specific failure if the peer presents such a certificate. > > > > There was pretty strong consensus to do #1 and I don't support removing > > it. That seems like a pretty modest layering violation. If people think > that > > the mandate for this specific alert is too onerous, I could live with > > removing > > that. > > I don't understand how you can have (1) and not (2). > As Ilari suggests, you could just treat the algorithms as unknown. Unlike Viktor (though I also don't like the layering violation) I'm not > proposing removing that text altogether, but tweaking it to allow > opportunistic and other TLS usage. > > Instead of altogether forbidding certs with MD5 signatures, forbid them > when the application expects TLS to authenticate the server [with PKIX, > as opposed to certain DANE usage values, or with pre-shared certs, > etc.]. I.e., a server authentication security level knob is needed. > I don't think that the current text prohibits that, because of : The signatures on certificates that are self-signed or certificates that are trust anchors are not validated since they begin a certification path (see [RFC5280], Section 3.2). A certificate that begins a certification path MAY use a signature algorithm that is not advertised as being supported in the "signature_algorithms" extension. In this case, I think one can argue are treating this as a trust anchor. Feel free to propose new text that you think makes that clearer. -Ekr > Nico > > > On Tue, May 23, 2017 at 2:46 AM, Viktor Dukhovni <ietf-d...@dukhovni.org > > > > wrote: > > > > On May 22, 2017, at 1:37 PM, Salz, Rich <rs...@akamai.com> wrote: > > > > I strongly believe the text should stay as it is, for the most good > to > > > the most people. Viktor is in the weeds, arguably by himself. > > > > > > Right, all by myself... With support from Nico, Ilari, and others > > > who've upthread accepted that certificate verification is properly > > > RFC5280 and not TLS, before I suggested removal of the text in > > > question (which solves no real problem, but does create needless > > > interoperability issues for various TLS use-cases). > > > > > > The dominant use case is not the only one that needs consideration, > > > and text that breaks other use-cases is NOT just fine, and the TLS > > > WG really does need to think more broadly than the Web PKI. This is > > > not the HTTPS working group. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
