On Tue, Apr 11, 2017 at 2:25 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Tue, Apr 11, 2017 at 01:47:08PM -0700, Eric Rescorla wrote: > > Thanks for your comments. > > > > > 4.1.2. It is not defined what a server should do if encountered with a > > > ProtocolVersion of TLS 1.3. > > > > https://tlswg.github.io/tls13-spec/#supported-versions says: > > > > If this extension is not present, servers which are compliant with > > this specification MUST negotiate TLS 1.2 or prior as specified in > > [RFC5246], even if ClientHello.legacy_version is 0x0304 or > > later. Servers MAY abort the handshake upon receiving a ClientHello > > with legacy_version 0x0304 or later. > > I think that MAY abort should be removed. client_version field has > always been defined to be tolerant to higher values. > It seems like we are ossifyng that extension point. Otherwise it's very hard to interpret. But I'm willing to defer if the WG objects. > > However, as David Benjamin points out, it's not clear how one would > > handle this in practice, because HRR is an instruction to the client > > to do something, so if it can't parse that then the handshake fails. > > I think if one wanted to have new mandatory HRR extension, one could > just have it sent, resulting older clients blowing up. But those would > not be able to connect anyway. > That's what we have now :) > > > 4.3.2.1. The OID Filters extension on a first look seems quite > > > independent and unrelated to everything else in this document (seemed > > > quite a distraction that could have been in an appendix as well). > > > > This is a fair point, but it's been in the document a long time, > > so I think this would require WG Consensus. > > Also, I have no idea of exact contents of that extension (maybe some mail > to this list has those, but that won't do with RFCs), as I can interpret > the thing in multiple ways. Hmm.. I did think the text was reasonably clear, but maybe I am in too deep. > > > 4.4.2.2., 4.4.2.3. > > > I think the reference to RFC5081 should be replaced with RFC5270 which > > > obsoletes the former even though not explicitly. > > > > Indeed. Also, we are now explicitly prohibiting OpenPGP per discussion > > in Chicago. > > Also, maybe needs some text about possible future Certificate Types > (or are those akin to DNS classes: heavy objects dropped by bad idea > fairy? :-) ). > > Also, client_certificate_type looks to be still CH,EE, which is not > good if any future certificate types might get defined (or even if > just RPK is allowed). > Actually, I think this is still right. The reason is that this extension applies to the client's entire certificate message, not to each certificate, so it needs to be negotiated up front. -Ekr > > > B.4. > > > I believe it was discussed before, but I miss the AES-256-CCM > > > ciphersuites. If only one must be defined, it may be better to only > > > have the 256-bit variants (at least for the non-mac-truncated version) > > > > Open to WG feedback here as well. > > Also, who uses those? It seems like CCM is mostly for things, and those > don't use AES-256, as AES-128 already seems quite much for various IoS. > > Also, if one wanted special ciphersuite for things, I think there are > ones that are implementable in smaller space than AES CCM. > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
