Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?
On Wednesday, 2 October 2019 00:15:13 CEST Peter Gutmann wrote: > Hubert Kario writes: > >a lax DER parser sounds like an oxymoron to me... :) > > That's why I assumed it was an accident/error. Writing a spec that relies > on buggy parser implementations in order to work is asking for trouble. well, SEC 1 does not require the ECDSA-Sig-Value structure to be encoded with DER, it's TLS that does that (and I'd say for the better, given the multitude of ways you can encode SEQUENCE in BER...) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [Technical Errata Reported] RFC8446 (5868)
The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5868
--
Type: Technical
Reported by: Hubert Kario
Section: 4.2.3
Original Text
-
ECDSA algorithms: Indicates a signature algorithm using ECDSA
[ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]
and FIPS 186-4 [DSS], and the corresponding hash algorithm as
defined in [SHS]. The signature is represented as a DER-encoded
[X690] ECDSA-Sig-Value structure.
Corrected Text
--
ECDSA algorithms: Indicates a signature algorithm using ECDSA
[ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]
and FIPS 186-4 [DSS], and the corresponding hash algorithm as
defined in [SHS]. The signature is represented as a DER-encoded
[X690] ECDSA-Sig-Value structure as defined in [RFC4492].
Notes
-
There is a possibility for confusion as the ECDSA-Sig-Value has two conflicting
definitions in authoritative standards. TLS always used the following (see
RFC4492):
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
but the publicly accessible SECG SEC1 v2.0 (https://www.secg.org/sec1-v2.pdf)
defines it like this:
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER,
a INTEGER OPTIONAL,
y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL
}
I think using the RFC5480 in the Corrected Text would be cleaner than RFC4492,
but the former is not an existing reference, so we would need to update section
12 also.
Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.
--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s) : E. Rescorla
Category: PROPOSED STANDARD
Source : Transport Layer Security
Area: Security
Stream : IETF
Verifying Party : IESG
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?
On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote: > On Tue, Oct 1, 2019 at 5:27 AM John Mattsson > 40ericsson@dmarc.ietf.org> wrote: > > Dan Brown wrote: > > > ANSI X9.62-2005 was withdrawn in 2015 > > > > Ok, that TLS 1.3 is relying on a withdrawn publication that used to be > > behind a paywall is even worse. > > Ugh. > > > > Also, I expect FIPS 186-5 is nearly ready, and will specify much of > > > > ECDSA > > > > That NIST FIPS 186-5 will include all the details needed to implement > > ECDSA is great. > > > > >IETF has specs for sigs and their formats already, no? > > > > At the time when RFC 8446 was published, there was probably no quick and > > easy solution to the problem. But the fact that IETF has historically been > > fine with relying on specifications behind paywalls is part of the > > problem. > > If IETF had implemented a strong open-access policy a long-time ago, there > > would probably be an open-access version of ECDSA (NIST or IETF) a long > > time ago.. > > I agree with you about the policy here. To be honest, I just didn't notice > this; and it would probably need some github spelunking to figure out the > history of these references. > > If someone wanted to propose an erratum that would fix this, I would be > very appreciative. I just did propose an erratum for that. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?
On Wednesday, 2 October 2019 13:18:07 CEST Hubert Kario wrote: > On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote: > > On Tue, Oct 1, 2019 at 5:27 AM John Mattsson > > > 40ericsson@dmarc.ietf.org> wrote: > > > Dan Brown wrote: > > > > ANSI X9.62-2005 was withdrawn in 2015 > > > > > > Ok, that TLS 1.3 is relying on a withdrawn publication that used to be > > > behind a paywall is even worse. > > > > Ugh. > > > > > > Also, I expect FIPS 186-5 is nearly ready, and will specify much of > > > > > > ECDSA > > > > > > That NIST FIPS 186-5 will include all the details needed to implement > > > ECDSA is great. > > > > > > >IETF has specs for sigs and their formats already, no? > > > > > > At the time when RFC 8446 was published, there was probably no quick and > > > easy solution to the problem. But the fact that IETF has historically > > > been > > > fine with relying on specifications behind paywalls is part of the > > > problem. > > > If IETF had implemented a strong open-access policy a long-time ago, > > > there > > > would probably be an open-access version of ECDSA (NIST or IETF) a long > > > time ago.. > > > > I agree with you about the policy here. To be honest, I just didn't notice > > this; and it would probably need some github spelunking to figure out the > > history of these references. > > > > If someone wanted to propose an erratum that would fix this, I would be > > very appreciative. > > I just did propose an erratum for that. https://www.rfc-editor.org/errata/eid5868 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?
> On Oct 2, 2019, at 12:23, Hubert Kario wrote: > > Signed PGP part > On Wednesday, 2 October 2019 13:18:07 CEST Hubert Kario wrote: >> On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote: >>> On Tue, Oct 1, 2019 at 5:27 AM John Mattsson >> >>> 40ericsson@dmarc.ietf.org> wrote: Dan Brown wrote: > ANSI X9.62-2005 was withdrawn in 2015 Ok, that TLS 1.3 is relying on a withdrawn publication that used to be behind a paywall is even worse. >>> >>> Ugh. >>> > Also, I expect FIPS 186-5 is nearly ready, and will specify much of ECDSA That NIST FIPS 186-5 will include all the details needed to implement ECDSA is great. > IETF has specs for sigs and their formats already, no? At the time when RFC 8446 was published, there was probably no quick and easy solution to the problem. But the fact that IETF has historically been fine with relying on specifications behind paywalls is part of the problem. If IETF had implemented a strong open-access policy a long-time ago, there would probably be an open-access version of ECDSA (NIST or IETF) a long time ago.. >>> >>> I agree with you about the policy here. To be honest, I just didn't notice >>> this; and it would probably need some github spelunking to figure out the >>> history of these references. >>> >>> If someone wanted to propose an erratum that would fix this, I would be >>> very appreciative. >> >> I just did propose an erratum for that. > > https://www.rfc-editor.org/errata/eid5868 On the 5480 vs 4492 reference. 4492 is also in the DOWNREF registry so it’s okay on that front, but three’s no ASN.1 module. That ASN.;1 come from the ASNI X9.62 spec. I have a slight preference to refer to 5480 and just add the reference. spt signature.asc Description: Message signed with OpenPGP ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05
> On Oct 1, 2019, at 21:14, Eric Rescorla wrote: > > > > On Tue, Oct 1, 2019 at 1:04 AM John Mattsson > wrote: > Hi, > > I think draft-ietf-tls-oldversions-deprecate needs to update > draft-ietf-rtcweb-security-arch as well. > > draft-ietf-rtcweb-security-arch-20 uses DTLS and even talks about support of > DTLS 1.0. > > "Earlier drafts of this specification required DTLS > 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and > at the time of this writing some implementations do not support DTLS > 1.2; endpoints which support only DTLS 1.2 might encounter > interoperability issues." > > You should check if there are more drafts in the publication process that > needs to be updated. > > I don't particularly mind, but this text was actually the result of some > pretty extensive discussion and compromising in rtcweb, so it's not just as > simple as changing this text. You can change the text, but I do not believe it will change the implementations. I would leave the text as is and NOT do an updates header. spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05
Hiya, On 02/10/2019 14:17, Sean Turner wrote: > You can change the text, but I do not believe it will change the > implementations. I would leave the text as is and NOT do an updates > header. WFM. I have executed that NOOP:-) S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS Key Separation PR
Since this had support in the room, we would really like to get a sense if there are any objections to this. Baring any negative comments, we’ll ask ekr to merge this on 10/7. spt > On Oct 1, 2019, at 23:40, Eric Rescorla wrote: > > Hi folks, > > As discussed in Montreal, I've prepared a PR to give us DTLS/TLS key > separation. > > See: > https://github.com/tlswg/dtls13-spec/pull/99 > > Sadly. we didn't have enough space for "dtls13 " so I went for "dtls13" > > -Ekr > > ___ > 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] I-D Action: draft-ietf-tls-external-psk-importer-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Importing External PSKs for TLS Authors : David Benjamin Christopher A. Wood Filename: draft-ietf-tls-external-psk-importer-01.txt Pages : 9 Date: 2019-10-02 Abstract: This document describes an interface for importing external PSK (Pre- Shared Key) into TLS 1.3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-external-psk-importer-01.txt
This update includes recent feedback received on the list and GitHub. There are three major changes: - Target KDFs instead of hash algorithms when importing external PSKs - Add an opaque "context" slot to the ImportedIdentity struct and describe its use for Selfie mitigations - Remove backwards compatibility ((D)TLS 1.2 and earlier) cruft (There's a silly formatting issue with the KDF table. We'll fix that in the next version.) Please have a look and provide feedback. PRs are welcome and highly encouraged. Looking ahead, there is one outstanding PR [1] that discussion. It deviates from an original goal of the importer, which was to not make any changes to TLS. There's also an issue to better document the importer security requirements and goals [2]. We are working on analyzing the importer and should be complete before Singapore, at which point we'll update the draft again. Best, Chris (no hat) On Wed, Oct 2, 2019, at 6:44 AM, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Importing External PSKs for TLS > Authors : David Benjamin > Christopher A. Wood > Filename: draft-ietf-tls-external-psk-importer-01.txt > Pages : 9 > Date: 2019-10-02 > > Abstract: >This document describes an interface for importing external PSK (Pre- >Shared Key) into TLS 1.3. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-01 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > 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] I-D Action: draft-ietf-tls-external-psk-importer-01.txt
Oops. Here are the referenced links: [1] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/10 [2] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/20 On Wed, Oct 2, 2019, at 6:54 AM, Christopher Wood wrote: > This update includes recent feedback received on the list and GitHub. > There are three major changes: > > - Target KDFs instead of hash algorithms when importing external PSKs > - Add an opaque "context" slot to the ImportedIdentity struct and > describe its use for Selfie mitigations > - Remove backwards compatibility ((D)TLS 1.2 and earlier) cruft > > (There's a silly formatting issue with the KDF table. We'll fix that in > the next version.) > > Please have a look and provide feedback. PRs are welcome and highly > encouraged. > > Looking ahead, there is one outstanding PR [1] that discussion. It > deviates from an original goal of the importer, which was to not make > any changes to TLS. There's also an issue to better document the > importer security requirements and goals [2]. We are working on > analyzing the importer and should be complete before Singapore, at > which point we'll update the draft again. > > Best, > Chris (no hat) > > On Wed, Oct 2, 2019, at 6:44 AM, internet-dra...@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > Title : Importing External PSKs for TLS > > Authors : David Benjamin > > Christopher A. Wood > > Filename: draft-ietf-tls-external-psk-importer-01.txt > > Pages : 9 > > Date: 2019-10-02 > > > > Abstract: > >This document describes an interface for importing external PSK (Pre- > >Shared Key) into TLS 1.3. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-01 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > ___ > > 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] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05
Hi, Sean Turner wrote: > "You can change the text, but I do not believe it will change the > implementations." I would much rather have a future proof RFC that forbids negotiation of DTLS 1.0 with the knowledge that some implementations will temporary violate that, than having an RFC that long time in the future allows negotiation and use of DTLS 1.0. Eric Rescorla wrote: > "result of some pretty extensive discussion and compromising in rtcweb" That does not surprise me, but I think that is part of the problem. These things should mainly be decided by the TLS working group. Draft-ietf-rtcweb-security-arch mandated DTLS 1.0 until Nov 2018. That is half a year after the "Deprecating TLSv1.0 and TLSv1.1" draft was submitted and almost 7 years after DTLS 1.0 was made obsolete. No matter what is done in this particular case, I think the important thing to discuss is how we avoid drafts that only support obsolete versions of TLS/DTLS in the future. According to my understanding of the comments in the thread "Lessons learned from TLS 1.0 and TLS 1.1 deprecation", both me, Kathleen Moriarty, and Martin Thomson understands obsoleted as: "New implementations and deployments MUST include support of the new version". If this is not clearly defined somewhere, I think it needs to be specified. If it is specified somewhere, IETF needs to make sure to follow apply it. Cheers, John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?
I concur with Hubert, and think that DER in this context is perfectly OK. On 10/2/19, 6:59 AM, "TLS on behalf of Hubert Kario" wrote: On Wednesday, 2 October 2019 00:15:13 CEST Peter Gutmann wrote: > Hubert Kario writes: > >a lax DER parser sounds like an oxymoron to me... :) > > That's why I assumed it was an accident/error. Writing a spec that relies > on buggy parser implementations in order to work is asking for trouble. well, SEC 1 does not require the ECDSA-Sig-Value structure to be encoded with DER, it's TLS that does that (and I'd say for the better, given the multitude of ways you can encode SEQUENCE in BER...) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
Hi, Please find some comments on the draft. In the introduction, I believe both limitations may be merged into one limitation which is the number of ticket is a server only decision. The purpose of the extension is the client providing information so the server can pick the appropriated number. I find "choose" and "hard-coded" a bit contradicting. If the server uses a hard coded value for the number of tickets, then I would understand the limitation as the server being unable to chose a value per client or per connection. This seems to me an implementation limitation and so maybe out of scope of the extension. If it is able to choose that number, the limitation is that it is a server only decision. I understand the meaning of count is the higher limit of ticket and the server can provides any tickets between 0 and count. If that is correct, this could be clearly stated and indication to chose an appropriated value for each cases may be provided. I would rather see the count value as a hard line from the server with a MUST NOT instead of a SHOULD NOT statement. My reading of 8446 is that NewSessionTicket messages can be sent at multiple time during or after the handshake. If that is correct, it seems to me quite complex to track the number of tickets that had been sent. Typically, if I have to send them at different time how much would I send at each flight. I would rather consider the min(count, server_limit) as the number of tickets in any batch of NewSessionTicket messages. We may also ask the client to only keep the latest batch of tickets and delete the others previously sent tickets. The ability to request 255 tickets with one byte can be seen as an amplification vector, especially when a server sends directly the tickets after its Finished message. I believe that additional text in the security consideration could be added. Yours, Daniel On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood wrote: > > > On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote: > > On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote: > > > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote: > > > > > > ``` > > > > > > Servers MUST NOT send more than 255 tickets to clients. > > > > > > ``` > > > > > > > > > > > > per what? session? at a time? connection? > > > > > > > > > > This is all per session. We can state it explicitly in the next > version. > > > > > > > > so this count needs to be kept as part of session and impacts > connections > > > > that perform resumption? > > > > > > Sorry, I meant connection: > > > > > >"Clients may indicate to servers their desired number of tickets > for *a > > > single connection* via the following "ticket_request" extension" > > > > > > This is a simple hint for servers. Nothing more. No state needs to be > stored > > > past connection establishment. > > > > sounds good > > > > > > > > what's the expected behaviour with tickets and post-handshake > > > > > > authentication? Are tickets sent after PHA also bound by this > limit? > > > > > > > > > > As mentioned earlier, there is no effect, so we left it out. We're > happy > > > > > to > > > > > accept text should you think it's needed. > > > > > > > > If the I-D states that servers should not send more tickets than the > > > > client > > > > asked for, and then send exactly that amount, then they won't be > able to > > > > send new tickets after PHA and remain compliant. > > > > > > > > Yes, it's completely up to the server to decide if to send tickets > after > > > > PHA or not, and I'm not suggesting that the client should request for > > > > tickets in one of its PHA messages, much less expect or require > them, but > > > > sending tickets after PHA is reasonable and explicitly stated > behaviour: > > > > > > > > RFC 8446 Section 4.6.1: > > > >For instance, the server might send a new > > > >ticket after post-handshake authentication in order to encapsulate > > > >the additional client authentication state. > > > > > > > > so the I-D should explicitly state what's the expected behaviour in > that > > > > case. > > > > > > > > IMHO, the extension should be used for the tickets sent right after > the > > > > handshake, it should not put an upper bound for the tickets that a > server > > > > can send in a single connection. For a very long lived connection > > > > (especially if the connection uses KeyUpdate messages regularly), the > > > > initial tickets may expire. Server may notice that and send a new > group > > > > of tickets then. > > > Since these hints are not mandatory to honor I don't think we need to > > > describe this case. In particular, this is a valid case where ignoring > the > > > SHOULD is fine, in my opinion. > > > > > > If the draft required that servers MUST NOT send more tickets than > what's > > > requested, then yes, I think these details would be important. > > > > huh? I see the following in the draft-02: > > > >Servers MUST NOT > >send more than 255 tickets to client
Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
Hi Daniel, Please see inline below. On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote: > Hi, > > Please find some comments on the draft. > > In the introduction, I believe both limitations may be merged into one > limitation which is the number of ticket is a server only decision. The > purpose of the extension is the client providing information so the > server can pick the appropriated number. I'd prefer we didn't merge them, though admittedly I don't feel strongly about this one way or the other. > I find "choose" and "hard-coded" a bit contradicting. If the server > uses a hard coded value for the number of tickets, then I would > understand the limitation as the server being unable to chose a value > per client or per connection. This seems to me an implementation > limitation and so maybe out of scope of the extension. If it is able to > choose that number, the limitation is that it is a server only > decision. Indeed. I think this is fairly clear from the draft. How would you suggest this be clarified? > I understand the meaning of count is the higher limit of ticket and the > server can provides any tickets between 0 and count. If that is > correct, this could be clearly stated and indication to chose an > appropriated value for each cases may be provided. The document states this: A supporting server MAY vend TicketRequestContents.count NewSessionTicket messages to a requesting client, and SHOULD NOT send more than TicketRequestContents.count NewSessionTicket messages to a requesting client. Is this not sufficient clear? If not, how can it be improved? > I would rather see the count value as a hard line from the server with > a MUST NOT instead of a SHOULD NOT statement. As this is merely a hint from the client, I don't think this is necessary. > My reading of 8446 is that NewSessionTicket messages can be sent at > multiple time during or after the handshake. If that is correct, it > seems to me quite complex to track the number of tickets that had been > sent. Typically, if I have to send them at different time how much > would I send at each flight. I would rather consider the min(count, > server_limit) as the number of tickets in any batch of NewSessionTicket > messages. We may also ask the client to only keep the latest batch of > tickets and delete the others previously sent tickets. This behavior is orthogonal to the intent of the hint. Imagine, for example, clients sent no hint and servers decided to do what you describe above. The same issues would still exist (tracking some count sent on the server, deciding which tickets to use on the client, etc.). Thus, I don't think this would add much value. > > The ability to request 255 tickets with one byte can be seen as an > amplification vector, especially when a server sends directly the > tickets after its Finished message. I believe that additional text in > the security consideration could be added. The text lists this: Servers SHOULD place a limit on the number of tickets they are willing to vend to clients. Though we can add a parenthetical to indicate that failure to do so may result in doing more work that intended. Thanks for the feedback! Best, Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] IANA changes for draft-ietf-tls-exported-authenticator
Hi folks, draft-ietf-tls-exported-authenticator requires some IANA changes that were not discussed during WGLC. The proposed changes are below. Please let the list know by next week (10/9) if you object to them, and if so, please explain why. > Value: EXPORTER-server authenticator handshake context > DTLS-OK: Y > Recommended: Y > Reference: [ RFC-to-be ] > Note: > > Value: EXPORTER-client authenticator finished key > DTLS-OK: Y > Recommended: Y > Reference: [ RFC-to-be ] > Note: > > Value: EXPORTER-server authenticator finished key > DTLS-OK: Y > Recommended: Y > Reference: [ RFC-to-be ] > Note: Thanks! Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
Hi, Please see my comments. Yours, Daniel On Wed, Oct 2, 2019 at 4:55 PM Christopher Wood wrote: > Hi Daniel, > > Please see inline below. > > On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote: > > Hi, > > > > Please find some comments on the draft. > > > > In the introduction, I believe both limitations may be merged into one > > limitation which is the number of ticket is a server only decision. The > > purpose of the extension is the client providing information so the > > server can pick the appropriated number. > > I'd prefer we didn't merge them, though admittedly I don't feel strongly > about this one way or the other. > > > I find "choose" and "hard-coded" a bit contradicting. If the server > > uses a hard coded value for the number of tickets, then I would > > understand the limitation as the server being unable to chose a value > > per client or per connection. This seems to me an implementation > > limitation and so maybe out of scope of the extension. If it is able to > > choose that number, the limitation is that it is a server only > > decision. > > Indeed. I think this is fairly clear from the draft. How would you suggest > this be clarified? > The draft does not seem, in my opinion, to address the case when values are hard coded. OK hardcoded is just there to expose it cannot chose the value. It is fine. > > > I understand the meaning of count is the higher limit of ticket and the > > server can provides any tickets between 0 and count. If that is > > correct, this could be clearly stated and indication to chose an > > appropriated value for each cases may be provided. > > The document states this: > >A supporting server MAY vend TicketRequestContents.count >NewSessionTicket messages to a requesting client, and SHOULD NOT send >more than TicketRequestContents.count NewSessionTicket messages to a >requesting client. > > Is this not sufficient clear? If not, how can it be improved? > > > I would rather see the count value as a hard line from the server with > > a MUST NOT instead of a SHOULD NOT statement. > > As this is merely a hint from the client, I don't think this is necessary. > > I believe we could be more specific than a hint, and a server supporting the extension MUST NOT send more tickets then specified. This is what is expected when count is set to 0. > > My reading of 8446 is that NewSessionTicket messages can be sent at > > multiple time during or after the handshake. If that is correct, it > > seems to me quite complex to track the number of tickets that had been > > sent. Typically, if I have to send them at different time how much > > would I send at each flight. I would rather consider the min(count, > > server_limit) as the number of tickets in any batch of NewSessionTicket > > messages. We may also ask the client to only keep the latest batch of > > tickets and delete the others previously sent tickets. > > This behavior is orthogonal to the intent of the hint. Imagine, for > example, clients sent no hint and servers decided to do what you describe > above. The same issues would still exist (tracking some count sent on the > server, deciding which tickets to use on the client, etc.). Thus, I don't > think this would add much value. > > If the servers receives a count value and sends tickets right after the Finished message and after the post handshake authentication. How many messages do you expect to be sent at each round? I suggested to have count at each round, as the server does not know how the client expects to use these tickets. I have the impression the current text says count. > > > > The ability to request 255 tickets with one byte can be seen as an > > amplification vector, especially when a server sends directly the > > tickets after its Finished message. I believe that additional text in > > the security consideration could be added. > > The text lists this: > >Servers SHOULD place a limit on the number of tickets they are willing > to vend to clients. > > The draft mentions limitation of tickets to avoid computation of the server, and I was reading the limit as to limit that computation, in which case the limit addresses server's resource exhaustion. What I meant was the use of the extension with a spoofed IP address. > Though we can add a parenthetical to indicate that failure to do so may > result in doing more work that intended. > > Thanks for the feedback! > > Best, > Chris > > ___ > 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] I-D Action: draft-ietf-tls-ticketrequests-02.txt
On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote: > I've read the draft, it looks quite useful and reasonable. It would > be good to see this published. +1 > I have one idea (implemented in OpenSSL 1.1.1 on the server side) > that may be worth mentioning in this context (and perhaps even the > draft): > >- By default, OpenSSL TLS 1.3 servers only vend multiple (two) > tickets on full handshakes. Resumed sessions issue just one > ticket. > > This avoids unbounded linear growth in the number of tickets vended > to a client that makes many resumed connections even after reaching > its peak connection concurrency. Dumb clients that say they want so many tickets on resumption, and then store them all, and don't clear out older tickets fast enough... can get DoSed by a server than gives them what they asked for. This probably warrants a bit of text on the matter. Probably a SHOULD saying that clients should ask for only one ticket in resumptions (i.e., not use this extension) unless they are short of tickets. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood wrote: > > > I understand the meaning of count is the higher limit of ticket and the > > server can provides any tickets between 0 and count. If that is > > correct, this could be clearly stated and indication to chose an > > appropriated value for each cases may be provided. > > The document states this: > >A supporting server MAY vend TicketRequestContents.count >NewSessionTicket messages to a requesting client, and SHOULD NOT send >more than TicketRequestContents.count NewSessionTicket messages to a >requesting client. > > Is this not sufficient clear? If not, how can it be improved? > RFC2119 "SHOULD/SHOULD NOT" requirements are usually clearer with some examples of "valid reasons in particular circumstances to ignore a particular item" [RFC2119]. Otherwise, those requirements can be cryptic, and perhaps better-described by MAY or MUST language. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
On Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote: > On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood wrote: > > > > > I understand the meaning of count is the higher limit of ticket and the > > > server can provides any tickets between 0 and count. If that is > > > correct, this could be clearly stated and indication to chose an > > > appropriated value for each cases may be provided. > > > > The document states this: > > > > A supporting server MAY vend TicketRequestContents.count > > NewSessionTicket messages to a requesting client, and SHOULD NOT send > > more than TicketRequestContents.count NewSessionTicket messages to a > > requesting client. > > > > Is this not sufficient clear? If not, how can it be improved? > > RFC2119 "SHOULD/SHOULD NOT" requirements are usually clearer with some > examples of "valid reasons in particular circumstances to ignore a > particular item" [RFC2119]. Otherwise, those requirements can be > cryptic, and perhaps better-described by MAY or MUST language. I understand, though I'm not sure more text is needed here. If you disagree, can you please suggest text to make it more clear? Thanks, Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
On Wed, Oct 2, 2019, at 4:04 PM, Nico Williams wrote: > On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote: > > I've read the draft, it looks quite useful and reasonable. It would > > be good to see this published. > > +1 > > > I have one idea (implemented in OpenSSL 1.1.1 on the server side) > > that may be worth mentioning in this context (and perhaps even the > > draft): > > > >- By default, OpenSSL TLS 1.3 servers only vend multiple (two) > > tickets on full handshakes. Resumed sessions issue just one > > ticket. > > > > This avoids unbounded linear growth in the number of tickets vended > > to a client that makes many resumed connections even after reaching > > its peak connection concurrency. > > Dumb clients that say they want so many tickets on resumption, and then > store them all, and don't clear out older tickets fast enough... can get > DoSed by a server than gives them what they asked for. > > This probably warrants a bit of text on the matter. Probably a SHOULD > saying that clients should ask for only one ticket in resumptions (i.e., > not use this extension) unless they are short of tickets. Asking for one upon resumption seems reasonable to me. Thanks to you and Viktor for bringing up this case! Best, Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
> On Oct 2, 2019, at 11:20 PM, Christopher Wood wrote: > > Asking for one upon resumption seems reasonable to me. Thanks to you and > Viktor for bringing up this case! Thanks! Much appreciated. My other point, which I probably obscured in too many words, is that a client that prefers to re-use existing tickets, would normally want to ask for 0 new tickets, but this should not necessarily preclude the server from issuing one *as needed* (STEK rollover, ...). So there is a difference between a signal that tickets are simply not wanted, vs. wanted only *as needed*. Do you have any thoughts on how a client might signal this? The use-case is clients and servers that don't make use of early-data, and don't need to avoid traffic analysis. For example, MTA-to-MTA traffic, where the client even identifies in clear text with "EHLO". Here ticket reuse is the norm, and renewal is only needed as tickets age. [ I hope I managed an suitably concise description this time... ] -- -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
On Thu, Oct 3, 2019 at 10:19 AM Christopher Wood wrote: > On Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote: > > On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood > wrote: > > > > > > > I understand the meaning of count is the higher limit of ticket and > the > > > > server can provides any tickets between 0 and count. If that is > > > > correct, this could be clearly stated and indication to chose an > > > > appropriated value for each cases may be provided. > > > > > > The document states this: > > > > > > A supporting server MAY vend TicketRequestContents.count > > > NewSessionTicket messages to a requesting client, and SHOULD NOT send > > > more than TicketRequestContents.count NewSessionTicket messages to a > > > requesting client. > > > > > > Is this not sufficient clear? If not, how can it be improved? > > > > RFC2119 "SHOULD/SHOULD NOT" requirements are usually clearer with some > > examples of "valid reasons in particular circumstances to ignore a > > particular item" [RFC2119]. Otherwise, those requirements can be > > cryptic, and perhaps better-described by MAY or MUST language. > > I understand, though I'm not sure more text is needed here. If you > disagree, can you please suggest text to make it more clear? > The current text the describes the interaction well enough, but I don't understand the requirement. I can suggest two alternatives: 1) A supporting server [...] MAY send more than TicketRequestContents.count NewSessionTicket messages to a requesting client. The client might not be able to use all of them. 2) A supporting server [...] MUST NOT send more than TicketRequestContents.count NewSessionTicket messages to a requesting client. The draft uses "SHOULD NOT". Why is that? Perhaps that trailing sentence I added to 1) seems obvious to the authors? I did not automatically assume the consequences of sending extra NewSessionTicket messages would be so innocuous. If that's the case, it seems like MAY would be better, since clients need to handle extra NewSessionTicket messages, even if they just discard them. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
