Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, 11 Apr 2018, Benjamin Kaduk wrote: I don't really agree with that characterization. To state my understanding, as responsible AD, of the status of this document: this document is in the RFC Editor's queue being processed. That was a process mistake. 1) ekr filed a DISCUSS 2) other people raised issues in response 3) ekr's DISCUSS was resolved but not the other people's concern 4) document was placed in RFC Editor queue despite this 5) TLS consensus call done on the list 6) here we are I think it is not good to use this process as a way of approving things. A process mistake was made. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters wrote: > On Wed, 11 Apr 2018, Benjamin Kaduk wrote: > > I don't really agree with that characterization. To state my >> understanding, >> as responsible AD, of the status of this document: this document is in the >> RFC Editor's queue being processed. >> > > That was a process mistake. > > 1) ekr filed a DISCUSS > 2) other people raised issues in response > 3) ekr's DISCUSS was resolved but not the other people's concern > 4) document was placed in RFC Editor queue despite this > 5) TLS consensus call done on the list > 6) here we are > > I think it is not good to use this process as a way of approving things. > A process mistake was made. > The question Ben was asking, though, is whether the impact of that process mistake is serious enough to merit pulling back the doc from the RFC editor. Personally, I think the answer is no, and I'm not hearing clear consensus in either direction in this thread. So ISTM the best information the chairs and ADs have to go on is the hum taken in the room (which all of the litigants here participated in), which was pretty clearly in favor of proceeding. --Richard > > Paul > > > ___ > 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] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt
Hi Richard, I work in the IoT space and am interested in handshakes that involve little computation but offer better protection than symmetric PSK in the event of server breach. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Richard Barnes Sent: 11 April 2018 15:54 […] We would love to hear any feedback on the approach proposed here, and on whether other people here would be interested in working on a PAKE mechanism for TLS in this working group. […] I was interested in this draft as it seemed to tick some boxes, and I offer some comments below. But in the end I don't think it offers what I'm looking for, so I can't offer to help with it in its current form. My main comment is that I disagree with the assertion in section 3 that "w" is effectively a salted password hash. An attacker who obtains "w" can impersonate the client to the server, so it is equivalent to a password. The only advantage is that a server breach cannot be extended to other servers where the user uses the same password, but different salts are used. It seems to me that SPAKE2+ prevents this, so perhaps this should be used instead. Secondly, SPAKE2 is fitted to the TLS 1.3 handshake by forcing the client to know the salt. This seems unreasonable to me unless there is also some mechanism to retrieve the salt from the server. Could the salt be a hash of client identity and server identity? (I suspect there is not enough entropy in this). But in any case I think this is an issue which must be addressed in the draft. Why does the draft need to specify what the identity of the server is? It doesn't seem to be used. Would it be helpful to send a list of SPAKE2Shares in ClientHello? For example, if the application layer protocol is being negotiated, would it be necessary to supply shares for multiple protocols? Alternatively, if the client and/or server support multiple pre-provisioned values (G, M, N, H), how would this be signalled/managed? And would there be associated security concerns? It is worth noting explicitly somewhere that x and y should have the same ephemeral characteristics as are used by the key_share elements, and that if this is followed then forward secrecy is provided by SPAKE2. IMHO "w" should not be used as the PSK input. If somebody gets hold of a derived key (e.g. early_exporter_master_secret) then the low entropy of "w" may allow it to be recovered. "K" provides all that's needed for key derivation. The draft should recommend somewhere (security section?) that H should be suitable for password hashing (e.g. Argon2) and not a standard hash function. This is particularly true if my earlier suggestion to use SPAKE2+ is followed. Regards, Tony Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK. This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment. Dyson may monitor email traffic data and content for security & training. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, 12 Apr 2018, Richard Barnes wrote: The question Ben was asking, though, is whether the impact of that process mistake is serious enough to merit pulling back the doc from the RFC editor. That can only be answered after the consensus call. I don't think anyone is really objecting as long as the document isn't forwarded to publication without completing the current discussion. Personally, I think the answer is no, and I'm not hearing clear consensus in either direction in this thread. So ISTM the best information the chairs and ADs have to go on is the hum taken in the room (which all of the litigants here participated in), which was pretty clearly in favor of proceeding. Again, from a process point of view, we do work on the lists. Humms can be used to gage the room on what direction to suggest to the WG, but all those actions are confirmed on their respective lists. In this case, both Viktor and I believe the room was not sufficiently aware of the issues raised. And I believe it was a good call for the IESG to move this discussion back onto the list. It would be odd to then take that hum back into account again for the consensus call on the list. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 12, 2018 at 9:46 AM, Paul Wouters wrote: > On Thu, 12 Apr 2018, Richard Barnes wrote: > > The question Ben was asking, though, is whether the impact of that process >> mistake is serious enough to merit pulling back the doc from the RFC editor. >> > > That can only be answered after the consensus call. I don't think anyone > is really objecting as long as the document isn't forwarded to publication > without completing the current discussion. > > Personally, I think the answer is no, and I'm not hearing clear consensus >> in either direction in this thread. So ISTM the best information the >> chairs and ADs have to go on is the hum >> taken in the room (which all of the litigants here participated in), >> which was pretty clearly in favor of proceeding. >> > > Again, from a process point of view, we do work on the lists. It seems noteworthy, however, that nobody is chiming in on the list who was not also part of the discussion in the room. That seems to me to indicate that their views were already heard and taken into account in the in-person discussion. --Richard > Humms can > be used to gage the room on what direction to suggest to the WG, but > all those actions are confirmed on their respective lists. > > In this case, both Viktor and I believe the room was not sufficiently > aware of the issues raised. And I believe it was a good call for the > IESG to move this discussion back onto the list. It would be odd to > then take that hum back into account again for the consensus call on > the list. > > Paul > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
There's a few steps Paul is missing in his summary of the process. On Thu, Apr 12, 2018 at 8:58 AM, Richard Barnes wrote: > > > On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters wrote: >> >> On Wed, 11 Apr 2018, Benjamin Kaduk wrote: >> >>> I don't really agree with that characterization. To state my >>> understanding, >>> as responsible AD, of the status of this document: this document is in >>> the >>> RFC Editor's queue being processed. >> >> >> That was a process mistake. >> >> 1) ekr filed a DISCUSS >> 2) other people raised issues in response >> 3) ekr's DISCUSS was resolved but not the other people's concern The concerns were discussed at the meeting in London. The chairs reviewed 3 separate issues. The first was agreed upon that a simple wording change that was not significant to hold up for approval was made. No change was needed with one of the other issues. With the third, the room was in full agreement that this should be done in a separate draft. I went to the mic and summarized this and asked for agreement that it was ok to approve the document as a result and there was no opposition, just agreement. It was right of the chairs to put this back out to the list for confirmation as they have the ability to pull a document back if they decide that is the right course of action. The AD can also override the chairs if they decide it should go forward and the AD does not agree (although I don't see that in his messages). Best regards, Kathleen >> 4) document was placed in RFC Editor queue despite this >> 5) TLS consensus call done on the list >> 6) here we are >> >> I think it is not good to use this process as a way of approving things. >> A process mistake was made. > > > The question Ben was asking, though, is whether the impact of that process > mistake is serious enough to merit pulling back the doc from the RFC editor. > > Personally, I think the answer is no, and I'm not hearing clear consensus in > either direction in this thread. So ISTM the best information the chairs > and ADs have to go on is the hum taken in the room (which all of the > litigants here participated in), which was pretty clearly in favor of > proceeding. > > --Richard > >> >> >> Paul >> >> >> ___ >> 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 > -- Best regards, Kathleen ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS and DTLS now on well-known RFC editor abbreviations list
I requested that the RFC editor add TLS and DTLS to their list of well-known abbreviations [0]. They agreed so now draft editors are free to expand (or not) TLS and DTLS in drafts. Note that the RFC editor also added SSL and SSL/TLS to the list. spt [0] https://www.rfc-editor.org/materials/abbrev.expansion.txt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 12, 2018 at 09:50:20AM -0400, Kathleen Moriarty wrote: > There's a few steps Paul is missing in his summary of the process. > > On Thu, Apr 12, 2018 at 8:58 AM, Richard Barnes wrote: > > > > > > On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters wrote: > >> > >> On Wed, 11 Apr 2018, Benjamin Kaduk wrote: > >> > >>> I don't really agree with that characterization. To state my > >>> understanding, > >>> as responsible AD, of the status of this document: this document is in > >>> the > >>> RFC Editor's queue being processed. > >> > >> > >> That was a process mistake. > >> > >> 1) ekr filed a DISCUSS > >> 2) other people raised issues in response > >> 3) ekr's DISCUSS was resolved but not the other people's concern > > The concerns were discussed at the meeting in London. The chairs > reviewed 3 separate issues. The first was agreed upon that a simple > wording change that was not significant to hold up for approval was > made. No change was needed with one of the other issues. With the > third, the room was in full agreement that this should be done in a > separate draft. I went to the mic and summarized this and asked for > agreement that it was ok to approve the document as a result and there > was no opposition, just agreement. It's also worth noting that Ekr explicitly disavowed the other concerns as outside the range of his DISCUSS (https://www.ietf.org/mail-archive/web/tls/current/msg25536.html), and the entire IESG had plenty of opportunities to indicate support for these other concerns as being DISCUSS-worthy, but none did so. > It was right of the chairs to put this back out to the list for > confirmation as they have the ability to pull a document back if they > decide that is the right course of action. > > The AD can also override the chairs if they decide it should go > forward and the AD does not agree (although I don't see that in his > messages). I'm waiting to see if anything else comes out of this thread. In particular, I am hoping that some authors/proponents of leaving the document in the RFC Editor queue would speak to the question of the target scope, given the arguments that have been presented regarding the risk/reward tradeoff of the current narrow scope. -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
Sorry for being confusing. I meant to say full Denial of Existing is in the draft implicitly already (because of the reference to DANE authentication according to RFC6698 and RFC7671 (which do mention it) in Section 6). I do like the idea of STS for this extension (and augment it with the more restrictive DANE use cases), but I'm unsure about the security of a built-in version. I notice that existing STS documents (HSTS [RFC6797] and MTA-STS [draft-ietf-uta-mta-sts]) are all one layer above TLS. Is a STS TTL conveyed in a ServerHello message secure when it would be just for SSL? I can see this might be different for the DANE use case because of the signed statements that come alongside the TTL, but for example... In case of built-in STS with the extension, what does a 0 TTL mean? - When 0 has been the only value seen ever, it is clear to me that the mechanism is equivalent with what we have in the draft now, but.. - When another value has been seen before, is a value of 0 then enough to clear the pin? Or would a DoE proof (or insecurity proof) alongside it be necessary? In case of the latter, what does that mean for sites that do have DANE records, but no servers that support the extension? Can they be hampered (for an indefinite period) by a MiTM? That would be really bad for DANE deployment. Op 10-04-18 om 17:22 schreef Paul Wouters: > On Tue, 10 Apr 2018, Willem Toorop wrote: > > I just want to clarify one misconception in Willem's statement. See my > previous emails to thist list for my full arguments on this issue. > >> The chain extension already contains verification of Denial Of Existence >> proofs, because that is needed for verifying wildcard expansions. > > This might confuse people. I am talking about denial of existence of any > TLSA record. You are talking about proof of non-existance of other TLSA > records besides the one you are returning. These are completely > different issues. I just want to ensure people realise when I said we > need proof of non-existence, that people do not read your line "already > contains this" as me being wrong. > > >> It does not explicitly mention the fallback to non-PKIX with a Denial of >> Existence proof or insecurity proof for the TLSA record, because it is >> (currently) irrelevant when the extension could simply be left out too. > > So that's not one bug, but two bugs. Defining them out of scope is not > what we should do. For instance, the document could already assume that > the proof of TLS extension (pinning) is going to be solved elsewhere, > and therefor a full denial of existence proof in this document would be > valuable. > > The document does not specify what to do when it does not find a TLSA > record to include. It does state: > > If the server is configured for DANE > authentication, then it performs the appropriate DNS queries, builds > the authentication chain, and returns it to the client. > > So if the server is configured for DANE, and it only finds denial of > existence proofs of its own TLSA record, what is the expected behaviour? > > This hints at returning the proof of non-existence, but clearly even the > authors are now saying they did not mean this and a server is not > required to do this. Clearly the text needs clarification, and if it > then leaves out denial of existence, it needs a justification for that > as well. > > Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]
> On Apr 4, 2018, at 1:50 PM, Joseph Salowey wrote: > > If the answer to 1) is no then please indicate if you think the working group > should work on the document to include > > A) Recommendation of adding denial of existence proofs in the chain provided > by the extension > B) Adding signaling to require the use of this extension for a period of time > (Pinning with TTL) > C) Both While I am a vocal supporter of (C), I'd like to take a moment to explain why AT LEAST (A) is needed. * The present text requires (Section 3.4) that the server's response present a validated TLSA RRset: The first RRset in the chain MUST contain the TLSA record set being presented * The present text (Section 8) says: Green field applications that are designed to always employ this extension, could of course unconditionally mandate its use. Therefore such "green field" applications (presumably some of the ones ready to implement now) effectively mandate DNSSEC and TLSA records at the server, NOT JUST support for the extension. This needlessly limits the usability of such applications. The server domain cannot continue to support the extension and interoperate with the client if it at some points decides to stop publishing TLSA records or perhaps even stop using DNSSEC. It makes a lot more sense for servers to be able to continue to support the extension, but respond with denial of existence when when the have no TLSA records or the zone is unsigned (no DS RRs at some ancestor). That way a server can communicate its change of status to a client, which may *then* be willing to accept alternative authentication (WebPKI, for example). Option (A) does not change the wire formats, it just relaxes the requirement to provide TLSA records, and would allow or encourage the server to return whatever is the truth about its TLSA records (presense, absence or unsigned zone). The client can then act accordingly. Just (A) would of course still many clients in the dark about when it might be safe to "mandate" the extension for particular domains, and I'd be sad about that (if anyone cares :-), but it is important to realize that not doing (A) is a significant omission. I'd like to encourage the authors and WG to amend the draft to relax section 3.4 to allow (and encourage when applicable) denial of existence replies. This would better serve the "green field" applications that would like to avail themselves of this extension and require it of all servers, whether they have DNSSEC and TLSA records or not. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [dane] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]
> * The present text (Section 8) says: > > Green field applications that are designed to always employ this >extension, could of course unconditionally mandate its use. > > Therefore such "green field" applications (presumably some of the ones > ready to implement now) effectively mandate DNSSEC and TLSA records > at the server, NOT JUST support for the extension. Viktor, I believe you have confused a "could" with a "mandate". The text of this RFC does not require future green field applications to mandate the use of this exension. It merely allows them to do so. None need ever do so. If any ever did, the future RFC could specify how servers which do not have validated TLSA records should handle the situation. Different future protocols might choose different ways to handle this (e.g. don't send the extension at all; or send a validated denial; or send some kind of flag saying that the server doesn't even have a validated denial because it isn't using DNS or because some domain on its path to the DNS root isn't doing DNSSEC or isn't using NSECx records). Please, let this RFC go, rather than requiring that this committee first insert into it a paper spec for what some future protocol should do, without even knowing what the future protocol is. John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 12, 2018, at 2:20 PM, Willem Toorop wrote: > > I notice that existing STS documents (HSTS [RFC6797] and MTA-STS > [draft-ietf-uta-mta-sts]) are all one layer above TLS. Is a STS TTL > conveyed in a ServerHello message secure when it would be just for SSL? The reason for that of course is that those "STS-flavours" are commitments to do TLS vs plaintext, and so can't presume TLS as a transport. The question being settled is whether the peer does TLS or not. > I can see this might be different for the DANE use case because of the > signed statements that come alongside the TTL, but for example... Here the issue not whether TLS is supported, but whether the TLS support includes support for this extension, and so TLS as a transport is both natural and simultaneously supports all relevant applications, rather than having to add per-application mechanisms. > In case of built-in STS with the extension, what does a 0 TTL mean? > > - When 0 has been the only value seen ever, it is clear to me that the >mechanism is equivalent with what we have in the draft now, but.. Yes. Don't pin, we're not promising ongoing support for the extension. > > - When another value has been seen before, is a value of 0 then enough >to clear the pin? Or would a DoE proof (or insecurity proof) >alongside it be necessary? > >In case of the latter, what does that mean for sites that do have >DANE records, but no servers that support the extension? Can they >be hampered (for an indefinite period) by a MiTM? That would be >really bad for DANE deployment. * Positive TTL values require TLSA records, denial of existence should not be able to set a positive value. * Once a positive TTL is in effect it can only be set back to 0 in one of two ways: 1. Along with TLSA records that authenticate the handshake. (possibly limited to PKIX-EE/TA per application profile) 2. Along with DNSSEC-authenticated denial of existence of said TLSA records or of zone security. That is downgrades to not pinning require more than a mis-issued WebPKI certs. The domain should either prove non-existence of signed TLSA RRs, or signal a 0 TTL along with valid TLSA RRs that match the cert chain. You can think of the above as an initial draft of the text for option (C). -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 12, 2018 at 08:20:22PM +0200, Willem Toorop wrote: > Sorry for being confusing. I meant to say full Denial of Existing is in > the draft implicitly already (because of the reference to DANE > authentication according to RFC6698 and RFC7671 (which do mention it) in > Section 6). > > > I do like the idea of STS for this extension (and augment it with the > more restrictive DANE use cases), but I'm unsure about the security of a > built-in version. > > I notice that existing STS documents (HSTS [RFC6797] and MTA-STS > [draft-ietf-uta-mta-sts]) are all one layer above TLS. Is a STS TTL > conveyed in a ServerHello message secure when it would be just for SSL? One has to wait for the handshake to complete for most cases (basically all except the "clear pins with DoE" case). > I can see this might be different for the DANE use case because of the > signed statements that come alongside the TTL, but for example... > In case of built-in STS with the extension, what does a 0 TTL mean? > > - When 0 has been the only value seen ever, it is clear to me that the > mechanism is equivalent with what we have in the draft now, but.. > > - When another value has been seen before, is a value of 0 then enough > to clear the pin? Or would a DoE proof (or insecurity proof) > alongside it be necessary? The way I understand it would work, it would clear the pin at end of handshake (one could clear immediately on DoE, but maybe better to delay that too). > In case of the latter, what does that mean for sites that do have > DANE records, but no servers that support the extension? Can they > be hampered (for an indefinite period) by a MiTM? That would be > really bad for DANE deployment. That type of attack is possible in some scenarios: - The DANE records pin a CA and MITM can get misissued certificate from that CA. - The server private keys get stolen. Since the MITM would need to present a key that exists in the DANE records in order to actually activate this pinning. Recovery would need deploying the extension (the data needed is public in DNS). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [dane] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]
> On Apr 12, 2018, at 2:44 PM, John Gilmore wrote: > > If any ever did, the future RFC could specify > how servers which do not have validated TLSA records should handle the > situation. They'd have to violate the text of this draft: > Different future protocols might choose different ways > to handle this (e.g. don't send the extension at all; or send a validated > denial; The draft precludes sending denial of existence in Section 3.4 which requires to the first RRset to be the requested TLSA records. Hence option (A) in the initial last-call announcement. > or send some kind of flag saying that the server doesn't even have > a validated denial because it isn't using DNS That'd be vulnerable to downgrade, defeating the purpose of this extension to support DANE. > or because some domain on > its path to the DNS root isn't doing DNSSEC or isn't using NSECx records). This can be handled by sending denial of existence. The denial of existence can either prove lack of TLSA records in the server's signed zone, or can prove lack of signatures on that zone. > > Please, let this RFC go, rather than requiring that this committee > first insert into it a paper spec for what some future protocol should > do, without even knowing what the future protocol is. The present draft limits its own applicability, and neither (A) nor (C) close off future options. Indeed (A) specifically lifts an unfortunate restriction, and (C) provides additional information from the server that would be quite useful to clients. It is hard to see how either preëmpt future use-cases. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [dane] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]
> On Apr 12, 2018, at 2:44 PM, John Gilmore wrote: > > Viktor, I believe you have confused a "could" with a "mandate". As to this point, I'm not now and have never been confused about that. The present draft, as explained upthread, perhaps in too many ways and in too many words, offers no value to applications that don't mandate the use of the extension, if the application also excepts WebPKI, and the extension is optional, then a cost/benefit analysis shows that use of the DANE extension offers only complexity and no security benefit. Opportunistic use-cases of the present draft won't get deployed, they make no sense. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On 4/12/18 9:54 AM, Benjamin Kaduk wrote: > I'm waiting to see if anything else comes out of this thread. > In particular, I am hoping that some authors/proponents of leaving the > document in the RFC Editor queue would speak to the question of the > target scope, given the arguments that have been presented regarding > the risk/reward tradeoff of the current narrow scope. I'm also waiting to see if something new comes up in the discussion, but it seems at this point we're just rehashing previous discussion and nothing much is changing. In particular, no new information is being contributed. The one thing that could change my mind about this would be if there was an intent to actually attack the problem described in the changed scope (well, also if the proposed change could - in fact - lead to the deprecation of the web PKI, but the chance of that seems vanishingly small). Absent that I really don't like adding goo to protocols on the off chance that at some unforeseeable point in the future there's a possibility that someone might actually want to use that feature. I think we've got other ways of handling that eventuality and very little assurance that it will ever happen, anyway. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
If this is indeed about adding [goo], what prevents Viktor or Paul from proposing a new addition to the protocol in the form of a new I-D that enacts the changes they wish to see? On Fri, Apr 13, 2018 at 7:41 AM, Melinda Shore wrote: > On 4/12/18 9:54 AM, Benjamin Kaduk wrote: >> I'm waiting to see if anything else comes out of this thread. >> In particular, I am hoping that some authors/proponents of leaving the >> document in the RFC Editor queue would speak to the question of the >> target scope, given the arguments that have been presented regarding >> the risk/reward tradeoff of the current narrow scope. > > I'm also waiting to see if something new comes up in the > discussion, but it seems at this point we're just rehashing > previous discussion and nothing much is changing. In > particular, no new information is being contributed. > > The one thing that could change my mind about this would be > if there was an intent to actually attack the problem described > in the changed scope (well, also if the proposed change could - > in fact - lead to the deprecation of the web PKI, but the chance > of that seems vanishingly small). Absent that I really don't > like adding goo to protocols on the off chance that at some > unforeseeable point in the future there's a possibility that > someone might actually want to use that feature. I think we've > got other ways of handling that eventuality and very little > assurance that it will ever happen, anyway. > > Melinda > > > -- > Software longa, hardware brevis > > PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 > 34C0 DFB8 9172 9A76 DB8F > > ___ > 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension
This is in fact what I proposed in the room in London. Let's publish draft this as-is, and handle what they want as a follow-on. On Thu, Apr 12, 2018 at 5:47 PM, Martin Thomson wrote: > If this is indeed about adding [goo], what prevents Viktor or Paul > from proposing a new addition to the protocol in the form of a new I-D > that enacts the changes they wish to see? > > On Fri, Apr 13, 2018 at 7:41 AM, Melinda Shore > wrote: > > On 4/12/18 9:54 AM, Benjamin Kaduk wrote: > >> I'm waiting to see if anything else comes out of this thread. > >> In particular, I am hoping that some authors/proponents of leaving the > >> document in the RFC Editor queue would speak to the question of the > >> target scope, given the arguments that have been presented regarding > >> the risk/reward tradeoff of the current narrow scope. > > > > I'm also waiting to see if something new comes up in the > > discussion, but it seems at this point we're just rehashing > > previous discussion and nothing much is changing. In > > particular, no new information is being contributed. > > > > The one thing that could change my mind about this would be > > if there was an intent to actually attack the problem described > > in the changed scope (well, also if the proposed change could - > > in fact - lead to the deprecation of the web PKI, but the chance > > of that seems vanishingly small). Absent that I really don't > > like adding goo to protocols on the off chance that at some > > unforeseeable point in the future there's a possibility that > > someone might actually want to use that feature. I think we've > > got other ways of handling that eventuality and very little > > assurance that it will ever happen, anyway. > > > > Melinda > > > > > > -- > > Software longa, hardware brevis > > > > PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 > > 34C0 DFB8 9172 9A76 DB8F > > > > ___ > > 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 > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On 4/12/18 1:47 PM, Martin Thomson wrote: > If this is indeed about adding [goo], what prevents Viktor or Paul > from proposing a new addition to the protocol in the form of a new I-D > that enacts the changes they wish to see? Clearly nothing, and I think this would be a reasonable way forward. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 12, 2018, at 5:47 PM, Martin Thomson wrote: > > If this is indeed about adding [goo], what prevents Viktor or Paul > from proposing a new addition to the protocol in the form of a new I-D > that enacts the changes they wish to see? Why publish a crippled specification that needs immediate amendments that would require a second parallel extension to be defined and used by clients and servers to fix the issues in the current specification? And the time to get that second extension would effectively delay the publication of a usable protocol. The protocol as described prohibits denial of existence responses. Willem acknowledged (thus far in an off-list message) that that's an oversight that should be corrected, and such a correction is the substance of option (A). The protocol as described does not provide any mechanism for client to distinguish between servers that are ready to commit to the extension and those are not. This negates applicability in applications that exist in a world dominated by the WebPKI. Note that I also don't advocate any magical vision of the WebPKI going away any time soon. Indeed some of these applications (e.g. browsers) might choose to support only *at least* WebPKI, with DANE for optional hardening (PKIX-TA(0), PKIX-EE(1)), but the present draft provides no downgrade protection for this use-case. The additional commitment signal is a hint to clients, not an obligation, it carries negligible cost, and can be finalized now. It enables more potential applications, without going back to square-zero and doing another year in the IETF WG process to address the gap. Let's do the right thing and fix now. The entire cost is just a small delay, there is zero downside after that. No imposed complexity. Just an improved scope. We all want to get stuff published and out the door, but let's take a *little* extra time to make sure it is not needlessly crippled. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 12, 2018 at 6:09 PM, Viktor Dukhovni wrote: > > > > On Apr 12, 2018, at 5:47 PM, Martin Thomson > wrote: > > > > If this is indeed about adding [goo], what prevents Viktor or Paul > > from proposing a new addition to the protocol in the form of a new I-D > > that enacts the changes they wish to see? > > Why publish a crippled specification that needs immediate amendments that > would > require a second parallel extension to be defined and used by clients and > servers > to fix the issues in the current specification? And the time to get that > second > extension would effectively delay the publication of a usable protocol. > > The protocol as described prohibits denial of existence responses. Willem > acknowledged (thus far in an off-list message) that that's an oversight > that > should be corrected, and such a correction is the substance of option (A). > As I said in a previous message, I'll support relaxing the language in the draft to permit delivery of authenticated denial chains for future applications of the protocol - I think that's just adding or modifying a couple of lines to the draft, and no wire changes. Someone actually argued to me in person that the draft could be read as not explicitly prohibiting authenticated denial (for NXDOMAIN/NODATA), but if we want to allow it, I think it's best to be crystal clear. If we can get consensus on that, then you could write a separate extension to convey the pinning information and describe the additional behavior. That in combination with the existing draft would satisfy your use case. That would in fact be an incremental addition, and not a whole new parallel protocol. Implementers that are opposed to pinning would then just ignore this second draft (and not bother with the authenticated denial part of the first draft). Since it seems pretty clear you're not going to consensus on adding pinning to the current draft, I think you should pursue this approach. And then you can try to convince implementers and deployers, now or in the future, that they need to use both extensions in combination. -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Fri, Apr 13, 2018 at 8:09 AM, Viktor Dukhovni wrote: >> On Apr 12, 2018, at 5:47 PM, Martin Thomson wrote: >> >> If this is indeed about adding [goo], what prevents Viktor or Paul >> from proposing a new addition to the protocol in the form of a new I-D >> that enacts the changes they wish to see? > > Why publish a crippled specification that needs immediate amendments that > would > require a second parallel extension to be defined and used by clients and > servers > to fix the issues in the current specification? Three reasons: 1. It clears the current bind. 2. It's abundantly clear (to me at least) that there is no consensus that the specification is indeed crippled. 3. We build by increments all the time. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
Op 13-04-18 om 00:09 schreef Viktor Dukhovni: > The protocol as described prohibits denial of existence responses. Willem > acknowledged (thus far in an off-list message) that that's an oversight that > should be corrected, and such a correction is the substance of option (A). Well... I find it unfortunate that the line you were quoting from section 3.4 could be interpreted as prohibiting the possibility of denial of existence. So I am open to relaxing that text so that it can not be interpreted as such anymore yes. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> "RB" == Richard Barnes writes: RB> It seems noteworthy, however, that nobody is chiming in on the list who was RB> not also part of the discussion in the room. Not true. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 12, 2018, at 6:44 PM, Willem Toorop wrote: > > Well... I find it unfortunate that the line you were quoting from > section 3.4 could be interpreted as prohibiting the possibility of > denial of existence. So I am open to relaxing that text so that it can > not be interpreted as such anymore yes. Current text: The first RRset in the chain MUST contain the TLSA record set being presented. However, ... Proposed text: When the server has DNSSEC-signed TLSA records, the first RRset in the chain MUST contain the TLSA record set being presented. However, ... When the server either has no TLSA records, or its domain is not DNSSEC-signed, it is RECOMMENDED that the server return a denial of existence of either the TLSA records, or proof of insecure delegation at some parent domain, rather than omit the extension. Clients that are willing to fall back from DANE to some alternative mechanism may require the denial of existence to make that possible. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 12, 2018 at 3:09 PM, Viktor Dukhovni wrote: > > > > On Apr 12, 2018, at 5:47 PM, Martin Thomson > wrote: > > > > If this is indeed about adding [goo], what prevents Viktor or Paul > > from proposing a new addition to the protocol in the form of a new I-D > > that enacts the changes they wish to see? > > Why publish a crippled specification that needs immediate amendments that > would > require a second parallel extension to be defined and used by clients and > servers > to fix the issues in the current specification? And the time to get that > second > extension would effectively delay the publication of a usable protocol. > > The protocol as described prohibits denial of existence responses. Willem > acknowledged (thus far in an off-list message) that that's an oversight > that > should be corrected, and such a correction is the substance of option (A). > It would be good to get clarity on this. My understanding is that option a involved recommending (at some unspecified level) that people provide those responses, not just making it possible for them to do so. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni wrote: > > > > On Apr 12, 2018, at 6:44 PM, Willem Toorop wrote: > > > > Well... I find it unfortunate that the line you were quoting from > > section 3.4 could be interpreted as prohibiting the possibility of > > denial of existence. So I am open to relaxing that text so that it can > > not be interpreted as such anymore yes. > > Current text: > >The first RRset in the chain MUST contain the TLSA record set being >presented. However, ... > > Proposed text: > >When the server has DNSSEC-signed TLSA records, the first RRset in >the chain MUST contain the TLSA record set being presented. >However, ... > >When the server either has no TLSA records, or its domain is not >DNSSEC-signed, it is RECOMMENDED that the server return a denial >of existence of either the TLSA records, or proof of insecure >delegation at some parent domain, rather than omit the extension. >Clients that are willing to fall back from DANE to some alternative >mechanism may require the denial of existence to make that possible. > I believe that that this text would harm ineteroperability. The difficulty here is what the server knows about the clients behavior. Specifically, if the server serves TLSA records and then ceases doing without serving authenticated denial of existence, then it is unable to determine if this would cause clients to fail because it doesn't know if the client implements the text in the final paragraph. One could argue that current clients could pin, but that's totally extratextual, as opposed t having a noninteroperable behavior in the document. -Ekr > -- > Viktor. > > ___ > 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 12, 2018, at 6:34 PM, Shumon Huque wrote: > > Implementers that are opposed to pinning would then just ignore this second > draft (and not bother with the authenticated denial part of the first draft). The pin hint is NOT an obligation on the client or the server. It is OPTIONAL. Servers can send 0, and clients can just IGNORE the pin. It is far easier to ignore the additional field, than to specify a separate extension. > Since it > seems pretty clear you're not going to consensus on adding pinning to the > current > draft, I think you should pursue this approach. The consensus call is open until Apr 18th, we may not have heard from everyone yet... -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 12, 2018, at 7:10 PM, Eric Rescorla wrote: > > The difficulty here is what the server knows about the clients behavior. > Specifically, if the server serves TLSA records and then ceases doing > without serving authenticated denial of existence, then it is unable to > determine if this would cause clients to fail because it doesn't know if > the client implements the text in the final paragraph. One could argue > that current clients could pin, but that's totally extratextual, as opposed > t having a noninteroperable behavior in the document. How exactly does telling the client the truth (conveying correct DNS state about the TLSA records) harm interoperability??? Please explain the scenario in which something now fails??? -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 12, 2018 at 4:14 PM, Viktor Dukhovni wrote: > > > > On Apr 12, 2018, at 7:10 PM, Eric Rescorla wrote: > > > > The difficulty here is what the server knows about the clients behavior. > > Specifically, if the server serves TLSA records and then ceases doing > > without serving authenticated denial of existence, then it is unable to > > determine if this would cause clients to fail because it doesn't know if > > the client implements the text in the final paragraph. One could argue > > that current clients could pin, but that's totally extratextual, as > opposed > > t having a noninteroperable behavior in the document. > > How exactly does telling the client the truth (conveying correct > DNS state about the TLSA records) harm interoperability??? > > Please explain the scenario in which something now fails??? > I already did this in my previous email, but I'll try again. In the current document, there is no expectation that clients will pin the server's use of TLSA and therefore the server can safely stop using TLSA (or run a mixed server farm). However, because this text implies that the client *could* pin, in order to ensure interoperability the server would have to provide authenticated denial at the risk of connection failure with such clients. However the text also does not require that the server do so. Thus, a conformant client and a conformant server can fail if the server just stops using TLSA. -Ekr > -- > Viktor. > > ___ > 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 12, 2018, at 7:47 PM, Eric Rescorla wrote: > > In the current document, there is no expectation that clients will pin the > server's use of TLSA and therefore the server can safely stop using > TLSA (or run a mixed server farm). However, because this text implies > that the client *could* pin, in order to ensure interoperability the server > would have to provide authenticated denial at the risk of connection > failure with such clients. However the text also does not require that > the server do so. Thus, a conformant client and a conformant server > can fail if the server just stops using TLSA. Section 8 already says that some clients may require the extension. Providing denial of existence improves interoperability when all that the client requires is the extension, and given denial of existence might accept something else. Servers that support the extension really ought to provide denial of existence, if that's all they can do. Rather than suppress the extension, if the client demands the extension and the server can't provide it, interoperability is lost either way. If your concern is that the new text is "license" for the clients to arbitrarily require the extension in applications where servers have no reason to expect such behaviour, I have no objection to text that says that "the foregoing does not constitute a license for clients to require the extension where this is not expected application behaviour" or some such. The idea is however to encourage servers to provide the denial of existence, because it may be useful, and is not less interoperable than eliding the extension. Giving license to clients to then expect this from servers is not the intent here. I'm trying to sneak in underhanded pinning. That's not the goal. I'd like to see explicit pinning (or not) hints from the server, so we don't need to play guessing games. Servers that consistently return a TTL of zero would then be at liberty to drop the extension rather than deliver DoE (denial of existence) at any time. In your shoes I'd strongly advocate for the pin TTL, and make sure that it is set to zero by any servers that be sure to avoid the concerns that you're expressing. That way we don't have to play guessing games about client behaviour. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 12, 2018, at 7:47 PM, Eric Rescorla wrote: > > In the current document, there is no expectation that clients will pin the > server's use of TLSA and therefore the server can safely stop using > TLSA (or run a mixed server farm). However, because this text implies > that the client *could* pin, in order to ensure interoperability the server > would have to provide authenticated denial at the risk of connection > failure with such clients. However the text also does not require that > the server do so. Thus, a conformant client and a conformant server > can fail if the server just stops using TLSA. Another way of looking at this argument is that we should not recommend that servers should return denial of existence, because if we do, then servers that don't return denial of existence might find themselves less interoperable than those that do. So everyone should be less interoperable, so not that nobody is relatively disadvantaged. An honest assessment of the situation is that indeed returning denial of existence is more generally interoperable in the face of unknown client behaviour, and so should be recommended as suggested. I am only mildly sympathetic to the slippery slope argument that this may facilitate expectations of such behaviour in clients. We are not here to police future design decisions for fidelity to pure interpretations of the draft. If client expectations are desirable in future applications, and servers coöperate, then hooray, we have a specification that meets real world needs. That said, the proposed language is not intended to be ann a-priori license to "pin as you see fit" with no prior application-specific standard defining what constitutes interoperable behaviour. This specification provides a mechanism, not policy. Applications will have to define the relevant policy options. My goal all along has been to make sure that the mechanism is sufficiently flexible to accommodate a range of application policies. [ Thus also the proposal for the additional TTL hint, which supports a broader range of possible policies. ] If you'd like me to craft revised option (A) text, that includes a suitable caveat, I can try. Or you or someone else can propose an alternative. I only ask that it be honest about the server's options: serving the denial of existence (DoE) records does interoperate with a broader range of client policies. In an application where the extension is absolutely optional, i.e. clients MUST NOT (and do not in practice) expect consistent use by the server, returning the DoE records would not be substantively different from simply leaving out the extension. The client must be able to function in some fashion with the extension missing, whether legitimately or stripped. In applications where some clients expect downgrade protection the server returning DoE records continues to work and the one not returning them might not interoperate with clients that expect to consistently learn the truth (good news or bad) about the servers TLSA records. Does anyone want to propose better text? -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt
Hi everyone, Below is a pointer to a new I-D describing an approach for clients to request session tickets via a new post-handshake message. This is useful for applications that perform parallel connection establishment and racing, e.g., via Happy Eyeballs. It should also help reduce ticket waste. More uses and details are given in the document. We would very much appreciate feedback on the mechanism utility and design. Best, Chris Begin forwarded message: > From: internet-dra...@ietf.org > Date: April 12, 2018 at 8:07:35 PM PDT > To: David Schinazi , Christopher Wood > , Tommy Pauly , "Christopher A. Wood" > > Subject: New Version Notification for draft-wood-tls-ticketrequests-00.txt > > > A new version of I-D, draft-wood-tls-ticketrequests-00.txt > has been successfully submitted by Christopher A. Wood and posted to the > IETF repository. > > Name:draft-wood-tls-ticketrequests > Revision:00 > Title:TLS Ticket Requests > Document date:2018-04-12 > Group:Individual Submission > Pages:6 > URL: > https://www.ietf.org/internet-drafts/draft-wood-tls-ticketrequests-00.txt > Status: > https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/ > Htmlized: https://tools.ietf.org/html/draft-wood-tls-ticketrequests-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequests > > > Abstract: > TLS session tickets enable stateless connection resumption for > clients without server-side per-client state. Servers vend session > tickets to clients, at their discretion, upon connection > establishment. Clients store and use tickets when resuming future > connections. Moreover, clients should use tickets at most once for > session resumption, especially if such keying material protects early > application data. Single-use tickets bound the number of parallel > connections a client may initiate by the number of tickets received > from a given server. To address this limitation, this document > describes a mechanism by which clients may request tickets as needed > during a connection. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt
Hi Chris, Thanks for sharing this. It's a simple idea and seems generally useful. Do you have a use for the identifier and context? I can see that without them there is no way to distinguish between a response to a request and spontaneous ticket issuance, but I just can't see how that is a problem. I think that you want an extension for this. Otherwise, the server is going to explode when it sees a TicketRequest message. If you have an extension, then negotiating that extension might be used suppress spontaneous ticket issuance. That has a catch though: then a server can't issue new tickets that bind to updated state (such as might happen after a connection migration in QUIC). I don't know how much people care about that trade-off. Sorry I didn't catch these before. Cheers, Martin On Fri, Apr 13, 2018 at 1:15 PM, Chris Wood wrote: > Hi everyone, > > Below is a pointer to a new I-D describing an approach for clients to > request session tickets via a new post-handshake message. This is useful for > applications that perform parallel connection establishment and racing, > e.g., via Happy Eyeballs. It should also help reduce ticket waste. More uses > and details are given in the document. > > We would very much appreciate feedback on the mechanism utility and design. > > Best, > Chris > > Begin forwarded message: > > From: internet-dra...@ietf.org > Date: April 12, 2018 at 8:07:35 PM PDT > To: David Schinazi , Christopher Wood > , Tommy Pauly , "Christopher A. Wood" > > Subject: New Version Notification for draft-wood-tls-ticketrequests-00.txt > > > A new version of I-D, draft-wood-tls-ticketrequests-00.txt > has been successfully submitted by Christopher A. Wood and posted to the > IETF repository. > > Name:draft-wood-tls-ticketrequests > Revision:00 > Title:TLS Ticket Requests > Document date:2018-04-12 > Group:Individual Submission > Pages:6 > URL: > https://www.ietf..org/internet-drafts/draft-wood-tls-ticketrequests-00.txt > Status: > https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/ > Htmlized: https://tools.ietf.org/html/draft-wood-tls-ticketrequests-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequests > > > Abstract: > TLS session tickets enable stateless connection resumption for > clients without server-side per-client state. Servers vend session > tickets to clients, at their discretion, upon connection > establishment. Clients store and use tickets when resuming future > connections. Moreover, clients should use tickets at most once for > session resumption, especially if such keying material protects early > application data. Single-use tickets bound the number of parallel > connections a client may initiate by the number of tickets received > from a given server. To address this limitation, this document > describes a mechanism by which clients may request tickets as needed > during a connection. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > ___ > 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] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt
Scrub the bit about needing the extension. I read past Section 4 completely. The other comments are still relevant. On Fri, Apr 13, 2018 at 1:49 PM, Martin Thomson wrote: > Hi Chris, > > Thanks for sharing this. It's a simple idea and seems generally useful. > > Do you have a use for the identifier and context? I can see that > without them there is no way to distinguish between a response to a > request and spontaneous ticket issuance, but I just can't see how that > is a problem. > > I think that you want an extension for this. Otherwise, the server is > going to explode when it sees a TicketRequest message. > > If you have an extension, then negotiating that extension might be > used suppress spontaneous ticket issuance. That has a catch though: > then a server can't issue new tickets that bind to updated state (such > as might happen after a connection migration in QUIC). I don't know > how much people care about that trade-off. > > Sorry I didn't catch these before. > > Cheers, > Martin > > On Fri, Apr 13, 2018 at 1:15 PM, Chris Wood wrote: >> Hi everyone, >> >> Below is a pointer to a new I-D describing an approach for clients to >> request session tickets via a new post-handshake message. This is useful for >> applications that perform parallel connection establishment and racing, >> e.g., via Happy Eyeballs. It should also help reduce ticket waste. More uses >> and details are given in the document. >> >> We would very much appreciate feedback on the mechanism utility and design. >> >> Best, >> Chris >> >> Begin forwarded message: >> >> From: internet-dra...@ietf.org >> Date: April 12, 2018 at 8:07:35 PM PDT >> To: David Schinazi , Christopher Wood >> , Tommy Pauly , "Christopher A. Wood" >> >> Subject: New Version Notification for draft-wood-tls-ticketrequests-00.txt >> >> >> A new version of I-D, draft-wood-tls-ticketrequests-00.txt >> has been successfully submitted by Christopher A. Wood and posted to the >> IETF repository. >> >> Name:draft-wood-tls-ticketrequests >> Revision:00 >> Title:TLS Ticket Requests >> Document date:2018-04-12 >> Group:Individual Submission >> Pages:6 >> URL: >> https://www.ietf..org/internet-drafts/draft-wood-tls-ticketrequests-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/ >> Htmlized: https://tools.ietf.org/html/draft-wood-tls-ticketrequests-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequests >> >> >> Abstract: >> TLS session tickets enable stateless connection resumption for >> clients without server-side per-client state. Servers vend session >> tickets to clients, at their discretion, upon connection >> establishment. Clients store and use tickets when resuming future >> connections. Moreover, clients should use tickets at most once for >> session resumption, especially if such keying material protects early >> application data. Single-use tickets bound the number of parallel >> connections a client may initiate by the number of tickets received >> from a given server. To address this limitation, this document >> describes a mechanism by which clients may request tickets as needed >> during a connection. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> ___ >> 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] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt
Hi Martin, Please see inline below. > On Apr 12, 2018, at 8:53 PM, Martin Thomson wrote: > > Scrub the bit about needing the extension. I read past Section 4 > completely. The other comments are still relevant. No problem. > > On Fri, Apr 13, 2018 at 1:49 PM, Martin Thomson > wrote: >> >> >> Do you have a use for the identifier and context? I can see that >> without them there is no way to distinguish between a response to a >> request and spontaneous ticket issuance, but I just can't see how that >> is a problem. Yes — we’re currently working on an I-D that would use the context for “special” tickets. Depending on where that goes, if anywhere, we may or may not need to keep the context. As you suggest, distinguishing between responses and spurious NSTs doesn’t *seem* like a problem. Best, Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt
On Fri, Apr 13, 2018 at 1:55 PM, Christopher Wood wrote: > Yes — we’re currently working on an I-D that would use the context for > “special” tickets. Depending on where that goes, if anywhere, we may or may > not need to keep the context. As you suggest, distinguishing between > responses and spurious NSTs doesn’t *seem* like a problem. Maybe the right way to deal with this is to put an extensions block in the request. Then you only have to resolve the question of whether NST answers the ClientHello or this new message... ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On 4/12/18 6:55 PM, Viktor Dukhovni wrote: > If you'd like me to craft revised option (A) text, that includes a suitable > caveat, I can try. I'm okay with putting denial-of-existence in there as a should, but I do feel strongly that pinning belongs in a separate document. As I said earlier, I have a problem with putting features in protocols that nobody intends to use. It's bad enough when it happens by circumstance but doing it deliberately strikes me as a bad idea. And while this may not be your problem, it's very much mine: this kind of thing is bad for the IETF. It discourages participation (and, ironically, implementation) and it slows the process down further, with no clear benefit (getting back to the implementation question). I've gotten an earful from several implementers about this, and it concerns me. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt
> On Apr 12, 2018, at 9:07 PM, Martin Thomson wrote: > > On Fri, Apr 13, 2018 at 1:55 PM, Christopher Wood > wrote: >> Yes — we’re currently working on an I-D that would use the context for >> “special” tickets. Depending on where that goes, if anywhere, we may or may >> not need to keep the context. As you suggest, distinguishing between >> responses and spurious NSTs doesn’t *seem* like a problem. > > Maybe the right way to deal with this is to put an extensions block in > the request. Then you only have to resolve the question of whether > NST answers the ClientHello or this new message...’ Indeed. That might work just as well, if not better. In any case, as written right now, we prohibit servers from sending spurious NSTs if both parties negotiate request support. If implementations honor that requirement, we won’t have a distinguishing problem. We then need only decide what is the best encoding strategy for request identity/context, if desired. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 13, 2018, at 12:07 AM, Melinda Shore > wrote: > > I'm okay with putting denial-of-existence in there as a should, > but I do feel strongly that pinning belongs in a separate document. > As I said earlier, I have a problem with putting features in protocols > that nobody intends to use. It's bad enough when it happens by > circumstance but doing it deliberately strikes me as a bad idea. The great irony of the situation, is that present draft already describes pinning: If TLS applications want to mandate the use of this extension for specific servers, clients could maintain a whitelist of sites where the use of this extension is forced. The client would refuse to authenticate such servers if they failed to deliver this extension. And I've seen no discussion or working group consensus to *prohibit* such pinning, only observations that it would be rather fragile in general. What my proposal (B) (really (C), since (B) requires (A) as a foundation) provides first and *foremost* is the ability for servers to DISABLE pinning, by giving clients an upper bound pinning TTL of 0. If you don't want to see pinning, voice your support for (B) (really C) and have servers send a TTL of ZERO! Keep in mind that the proposed TTL is an upper bound, it is NOT an obligation to pin, and therefore is always a restriction on pinning, while at the same supporting a signal that pinning may be safe at the server's discretion. So this both serves the overall interoperability objectives voiced by Eric Rescorla, allows servers to disavow any pinning and supports future cases. It is a win-win, and carries ZERO implementation cost, on the server, if pinning is explicitly unwanted, just the field to zero and move along. On the client if no pinning is desired, just ignore the TTL. This feature is a win/win and carries no implementation burden, and the document is about to get a revision for (A) and still awaits an IANA code point assignment. If we act promptly on both (A) and (B) (i.e. (C)) there'll be zero additional delay. I sympathize strongly with the desire to keep specifications lean and mean, but that desire is misplaced here. The technical details do matter, and both supporting DoE and setting a max "pin" TTL are well motivated, improve interoperability and allow the server to opt-out of the sort of fragile ad-hoc pinning described in the draft. So please, let's not allow the general argument to deafen us to the specific context of this document. Though it needs at least (A) it also needs (B) (i.e. (C)). -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 12, 2018 at 9:40 PM, Viktor Dukhovni wrote: > > > On Apr 13, 2018, at 12:07 AM, Melinda Shore < > melinda.sh...@nomountain.net> wrote: > > > > I'm okay with putting denial-of-existence in there as a should, > > but I do feel strongly that pinning belongs in a separate document. > > As I said earlier, I have a problem with putting features in protocols > > that nobody intends to use. It's bad enough when it happens by > > circumstance but doing it deliberately strikes me as a bad idea. > > The great irony of the situation, is that present draft already > describes pinning: > >If TLS applications want to mandate the use of this extension for >specific servers, clients could maintain a whitelist of sites where >the use of this extension is forced. The client would refuse to >authenticate such servers if they failed to deliver this extension. > > And I've seen no discussion or working group consensus to *prohibit* > such pinning, only observations that it would be rather fragile in > general. > Thanks for pointing this out. I agree that this text is likely to cause interop problems and should be removed or at least scoped out in the case where client and server are unrelated. I regret that I didn't catch it during my IESG review. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 13, 2018, at 12:51 AM, Eric Rescorla wrote: > > Thanks for pointing this out. I agree that this text is likely to cause > interop problems and should be removed or at least scoped out in > the case where client and server are unrelated. I regret that I didn't > catch it during my IESG review. Well (B) is a proposal for doing just that, making it possible for servers to suppress any such pinning, but it also allows for future use-cases in which pinning might be desirable. If we're revising the text anyway, and given that implementors suffer no burden to insert (on the server) or ignore (on the client) an extra two bytes in the extension, (so Melinda's issue of added complexity is not a barrier here), the sensible responsive change is to add support for (B) with a requirements that clients not pin longer than requested, and servers should generally set the TTL to zero, unless pinning is understood to be fit for purpose in the given application, and the operator is willing to commit for the indicated time. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
