Re: [TLS] Multiple records in record limit (was: Secdir review)
On Mon, 2018-02-26 at 12:39 +1100, Martin Thomson wrote: > Out of the secdir review (thanks again Alan!), I realized that the > draft never actually said this: > >PMTU governs the size of UDP datagrams, which limits the size of > records, but >does not prevent records from being smaller. An endpoint that > sends small >records is still able to send multiple records in a single UDP > datagram. > > I think that I should add that explanation. > > Does anyone think that this should go further and advise against > putting multiple records in the same datagram? I'm not sure which part of the protocol text this would refer to, but DTLS1.2 says in https://tools.ietf.org/html/rfc6347#section-4.1.1 ``` Multiple DTLS records may be placed in a single datagram. They are simply encoded consecutively. ``` so even though I agree that the advice against putting multiple records in the same datagram is a good one (I'm not even sure if that works today with existing implementations), the advice seems against the original protocol. Shouldn't that text be in the upcoming DTLS1.3 rather than an update like record size limit which seems unrelated? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Thu, 22 Feb 2018, Shumon Huque wrote: On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters wrote: On Wed, 21 Feb 2018, Shumon Huque wrote: Okay, got it. For people that have already implemented this, I think there has been an implicit understanding that the format of the chain data is a sequence of concatenated wire format RRs exactly as they appear in a DNS message section Note, I would not call it "sequence of concatenated wire format RRs", as it is simply the wireformat of a DNS message. The fact that some parts are concatenated RR's is just part of the wireformat of the DNS reply message. That is, this isn't introducing some new form of concatenated content - it is _just_ a regular DNS wire format message, and the document should not go deeper into its explanation. It would _not_ be correct to say that this is a "DNS wire format message" - that would mean there is a DNS header section with flags and response codes, and other sections. The chain data structure as currently specified really is concatenated wire-format RRs (as they appear _within_ a DNS message _section_). Let me know if that is unclear in the draft (or my proposed edits). So it was decided to not use a full DNS packet format? And then since you miss the structure of the Answer Section and Additional/Authority Section, you require the "answer RR's" come first where you basically emulate an Answer Section? Isn't that an indication that we should really use the wireformat of an entire DNS message here? Maybe some DNS library/tools people can chime in here to tell us if this matters much to them (assuming they are adding support for creating/consuming these chains of RRsets in wire format. I am personally a little sad we cannot have a dig +chainquery command where we write out the entire answer packet format to a blob, to be loaded by the TLS server. And where a TLS client cannot just hand over the blob "as if it came in as a reply from a DNS server" to its DNS/cache receiving code path. I recall at one point way back there was a discussion about whether the chain data should just be a fully formed DNS message, but I don't believe that idea had much support in the working group (personally I would have been fine with that choice too, if it did have support). Do you remember why not? I'll see about checking the archives, but to me the hint that you are losing information and require some kind of ordering seems to suggest there is a need for using the full DNS message reply format. There is some residual wording in the draft about ordering of CNAMEs etc in the answer records part. Assuming the WG agrees, I am fine with relaxing that requirement - that ended up in there because although there is no defined ordering of RRs within a DNS message section, as a practical matter CNAMEs are almost always ordered since there are some DNS queriers that get confused otherwise. This is a new protocol though, so we can be more faithful to the DNS spec. I would prefer the residual wording to go away. Any hints at order being important should be squashed. I don't think getting unrelated DNSSEC records would be an issue. TLS has its maximum sizes for the handshake. In fact, it could allow the extension to have some useful data in the case of MX or SRV. (and could be a feature to build a nice resolver over TLS using 1 tor circuit). The draft currently doesn't address the MX or SRV use case. I suggest that we tackle that in a future version. Jus make sure the document doesn't forbid any such data, and allow the client to ignore these or put them in the cache as it sees fit. I'm also not sure about the talking of unsigned CNAME records from DNAME. The above pseudo code (extended with special cases) should be in some DNS library, and that library will know what records to expect unsigned which are proven by the DNAME (or wildcard) synthesis and knows when/if to add it to the validated cache. I don't think that should be explained in this RFC at all. The DNS implementation does not need to be specified in this document and it should just focus on saying that "the DNS message response is validated and upon validation the content can be considered DANE validated". Where we ended up, is that WG participants asked for some level of DNSSEC detail to be included in this doc. Again, that will only lead to bad implementations. There should be no need to update this document once something like ANAME, ALIAS or ZNAME is introduced to the DNS. So you should not talk about these things at all. TLS client should use a dns library that knows these things, or if they want to write one from scratch, these implementors should look at the DNS RFCs and not this RFC for guidance on how the DNS protocol works. Paul ___ TLS mailin
Re: [TLS] Multiple records in record limit (was: Secdir review)
On Feb 25, 2018, at 8:39 PM, Martin Thomson wrote: > > Out of the secdir review (thanks again Alan!), I realized that the > draft never actually said this: > > PMTU governs the size of UDP datagrams, which limits the size of records, > but > does not prevent records from being smaller. An endpoint that sends small > records is still able to send multiple records in a single UDP datagram. > > I think that I should add that explanation. > > Does anyone think that this should go further and advise against > putting multiple records in the same datagram? Yes. I don't think there's any good reason for that kind of behaviour. Alan DeKok. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Multiple records in record limit (was: Secdir review)
On Mon, Feb 26, 2018 at 7:48 AM, Alan DeKok wrote: > On Feb 25, 2018, at 8:39 PM, Martin Thomson > wrote: > > > > Out of the secdir review (thanks again Alan!), I realized that the > > draft never actually said this: > > > > PMTU governs the size of UDP datagrams, which limits the size of > records, but > > does not prevent records from being smaller. An endpoint that sends > small > > records is still able to send multiple records in a single UDP > datagram. > > > > I think that I should add that explanation. > > > > Does anyone think that this should go further and advise against > > putting multiple records in the same datagram? > > Yes. I don't think there's any good reason for that kind of behaviour. > There actually are. One example is packing handshake and data records in the same datagram. -Ekr > Alan DeKok. > > ___ > 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] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
> On Feb 26, 2018, at 9:26 AM, Paul Wouters wrote: > > So it was decided to not use a full DNS packet format? And then since you > miss the structure of the Answer Section and Additional/Authority > Section, you require the "answer RR's" come first where you basically > emulate an Answer Section? > > Isn't that an indication that we should really use the wireformat of an > entire DNS message here? Maybe some DNS library/tools people can chime > in here to tell us if this matters much to them (assuming they are > adding support for creating/consuming these chains of RRsets in wire > format. > > I am personally a little sad we cannot have a dig +chainquery command > where we write out the entire answer packet format to a blob, to be loaded by > the TLS server. And where a TLS client cannot just hand over the blob > "as if it came in as a reply from a DNS server" to its DNS/cache > receiving code path. The latter would require compression support on the receiving side, which has been specifically excluded so far. I am not against making the data more compact, though it is rather late in the process, but I have a more pressing issue. I think that as it stands, lack of authenticated denial of existence is a *fatal* flaw in the protocol. I just don't see a sufficiently practical scenario in which this extension confers a useful security benefit. Perhaps this draft should go back to the working group, to consider a new protocol element, by which the server commits to support the extension for a time that is substantially longer than the underlying DNS TTLs. During this time (suggested to be weeks or months, when in production after initial testing), the server MUST support the extension and respond with EITHER a valid TLSA RRset chain, or with a valid denial of existence. The protocol, thus extended, can then be seen as a more robust form of key pinning, in which pins are stored server-side, and only the fact that pinning is expected is stored client-side (for any length of time, the client may still do short-term caching of TLSA RRs based on the DNS TTL). The protocol is still subject to downgrade (to PKIX) on first contact, but is this a common element of all protocols that bootstrap security on first use. Indeed the WebPKI itself is largely TOFU as most certs (which are predominantly DV certs) are issued by CAs based on rather weak initial evidence. -- Viktor. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
