On Tue, May 23, 2017 at 6:00 AM, Nico Williams <[email protected]> wrote:
> On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote: > > On Tue, May 23, 2017 at 5:43 AM, Nico Williams <[email protected]> > > wrote: > > > On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote: > > > > On Tue, May 23, 2017 at 5:17 AM, Nico Williams < > [email protected]> > > > > wrote: > > > > > > 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. > > > > > > How does that square with (1)? > > > > > > > I don't understand the question. If you treat them as unknown then > > either your path construction code will route around them or once you > > try to verify, it will fail. > > That *really* seems like a layer violation! > As I said, I don't have a problem with it. It's TLS giving instructions to the PKI subsystem. > > Clients SHOULD/MUST NOT accept server certificates, or certificate > > > validation paths, where the server certificate or intermediate > > > certificates (but not trust anchors) are signed with "weak" > signature > > > algorithms, unless the client is not expecting TLS to strongly > > > authenticate the server (e.g., for opportunistic use) or where the > > > client has previously learned and cached the server's certificate. > > > > I don't think "strongly authenticate" is useful here. I think the > > requirement is that the RP must not accept these algorithms in any > > context which would require validating signatures made using them. > > Well, I want it to be crystal clear that the "not MD5 and such" > requirement need not apply to opportunistic TLS usage. I don't think "opportunistic" is a clearly enough defined category to be useful here. Rather, I think the relevant criterion is the one I listed above. If people agree, I'd be happy to make that change (and can produce text) because I think it conforms to the WG consensus. -Ekr
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
