Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

> This is the Working Group Last Call for "Delegated Credentials for TLS" > available at https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ > . Please review > the document and respond to the list with any comments by June 2, 202

Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

> On May 21, 2020, at 10:12 AM, Ryan Sleevi wrote: > > > On Wed, May 20, 2020 at 6:40 PM Russ Housley <mailto:hous...@vigilsec.com>> wrote: > MINOR > > Section 1 also says: > >Because the above problems do not relate to the CA's inherent >

Re: [TLS] adoption call for draft-dt-tls-external-psk-guidance

I support adoption. > On May 21, 2020, at 10:12 PM, Sean Turner wrote: > > This is a WG document adoption call for draft-dt-tls-external-psk-guidance > (aka Guidance for External PSK Usage in TLS). This effort was kicked off > @IETF106 by Ben Kaduk and supported by others in the audience. Ther

Re: [TLS] 3rd WGLC for draft-ietf-tls-exported-authenticators

> On May 22, 2020, at 9:23 AM, Sean Turner wrote: > > This is the 3rd WGLC for "Exported Authenticators in TLS" draft available at > https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. The > secdir review during IETF LC raised some issues and as a result there have > be

Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

Nick: There is something wrong with the formatting of the numbered list in Section 4.1.3. Russ > On Jun 3, 2020, at 4:20 PM, Nick Sullivan > wrote: > > Hello TLSWG, > > We made a -08 version of this draft before the WGLC that incorporated some of > the comments on-list for -07, but didn't

Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

Eric: > On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson > wrote: > I think that this is a useful erratum and it should be approved/HFDU. The > extension to which this text alludes is RFC 8773, not post_handshake_auth. > > Yes, although 8773 actually is not super-clear

Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

Martin: > I think that this is a useful erratum and it should be approved/HFDU. The > extension to which this text alludes is RFC 8773, not post_handshake_auth. > > There is one other piece to this that is very confusing, and less clear. > > "Servers which are authenticating with a PSK MUST NO

Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

Eric: >> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson > > wrote: >> I think that this is a useful erratum and it should be approved/HFDU. The >> extension to which this text alludes is RFC 8773, not post_handshake_auth. >> >> Yes, although 8773 actually is not super

Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

> On Jun 4, 2020, at 12:37 PM, Eric Rescorla wrote: > > > > On Thu, Jun 4, 2020 at 9:24 AM Russ Housley <mailto:hous...@vigilsec.com>> wrote: > Eric: > >>> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson >> <mailto:m...@lowentropy.net>> w

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

This update resolves the comments that I posted on the previous version. Thanks. Russ From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of Joseph Salowey Sent: Monday, June 29, 2020 5:59 PM To: mailto:tls@ietf.org>> mailto:tls@ietf.org>> Subject: [TLS] 2nd WGLC for Delegated Credentials for

Re: [TLS] comments on draft-subcerts

Rich: > Sec 4.2 doesn’t seem to agree with the complete ASN1 in Appendix A. The > latter has DelegatedCredentialExtn which is mentioned in prose and a TBD in > 4.2 Perhaps a comment or some other words to tie them together? Or does > that issue just go away when IANA does the registration?

Re: [TLS] comments on draft-subcerts

Watson: This does not look right to me. The extensions in the certificate are: extensions=Extensions: Extension: extnID=2.5.29.15 critical=True extnValue=0x03020780 Extension: extnID=2.5.29.37 critical=False extnValue=0x300a06082b06010505070301 Extension: e

Re: [TLS] comments on draft-subcerts

I have two comments: 1) The OID assignment for the ASN.1 module was assigned already by IANA. Please fill it in. 2) I think it would be very helpful to have an example of the extension in an Appendix. There was discussion on the list about it, and an error was found in the proposed example,

Re: [TLS] comments on draft-subcerts

, which format do you think would be most useful for the extension? I'm > having a hard time finding another extension to model this after. > > On Fri, Aug 14, 2020 at 10:00 AM Russ Housley <mailto:hous...@vigilsec.com>> wrote: > I have two comments: > > 1) The OID assi

Re: [TLS] comments on draft-subcerts

Yes, my first comment was addressed. Russ > On Aug 20, 2020, at 9:19 AM, Salz, Rich wrote: > > I've attempted to address the comments here: > https://github.com/tlswg/tls-subcerts/pull/80 >

Re: [TLS] Static DH timing attack

Peter: > Achim Kraus writes: > >> Does using x25519 for ECDHE is significant less secure than using it with >> e.g. secp384r1? > > The NIST curves AFAIK are never used that way, it's only done with 25519 > (there was something about it in an OpenPGP draft, but I think GPG went > straight to 255

Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"

Jonathan: Thanks for the review. > Here are my comments on the draft. > > 1. Section 4 covers a lot of ground and is difficult to follow. I > suggest it be split into subsections (e.g. "4.1 PSKs Shared with > Multiple Group Members" and "4.2 Weak Entropy PSKs") and move the > attack description

Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"

I made a PR with these changes. Russ > On Dec 21, 2020, at 9:30 AM, Jonathan Hammell wrote: > > Hi Russ, > > On Fri, Dec 18, 2020 at 1:55 PM Russ Housley wrote: >>> 1. Section 4 covers a lot of ground and is difficult to follow. I >>> suggest it be split

Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"

Ben: Thanks for you review and comments. > We've only had one review in response to the last call so far, I'd like to > see a few more reviews of this document before moving it forward. Are there > any volunteers who can commit to a review in the near future? > > I've reviewed and have only

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-10.txt

I have reviewed the recent update, and I notice one inconsistency. Section 2 says: In the absence of an application profile standard specifying otherwise, the maximum validity period is set to 7 days. Section 4.1.3 says: 1. Validate that DelegatedCredential.cred.valid_time is no more

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-10.txt

Works for me. > On Jan 31, 2021, at 11:58 PM, Sean Turner wrote: > > Do you think this would be clearer: > > The maximum validity period is set to 7 days unless > an application profile standard specifies a shorter > period. > > spt > >> On Jan 25,

Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"

Sean and Joe: The revision to address Ben' comments has now been posted. I believe that all WGLC comments have been addressed. I think this document is ready to go to the IESG. Russ > On Jan 22, 2021, at 3:27 PM, Russ Housley wrote: > > Ben: > > Thanks for you

[TLS] RFC 8998

This RFC includes: 3.3.3. Certificate When a server sends the Certificate message containing the server certificate to the client side, several new rules are added that will affect the certificate selection: * The public key in the certificate MUST be a valid SM2 public key. *

Re: [TLS] [Editorial Errata Reported] RFC2818 (6503)

This one should just be deleted. > On Mar 29, 2021, at 12:33 PM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC2818, > "HTTP Over TLS". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errat

Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc: redux

This document seems fine to me, but the first paragraph of Section 3 needs some work. This can be sorted out after adoption. Section 3 begins with: When a record with CID is received that has the source address of the enclosing UDP datagram different from the one previously associated

Re: [TLS] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

> In Section 7.1.4.1: the following text is removed: If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension. > Since it’s a MAY, I am a-okay with deleting. Anybody else see harm? I don't se

Re: [TLS] [Editorial Errata Reported] RFC2246 (6680)

This is noise. Please delete it. Russ > On Sep 8, 2021, at 8:02 AM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC2246, > "The TLS Protocol Version 1.0". > > -- > You may review the report below and at: > https://www.

[TLS] draft-ietf-tls-subcerts

What is going on with draft-ietf-tls-subcerts? A WG Last Call was held, and an issue was raised, but the document has not been updated since the WL Last Call closed about a year ago? Russ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/

Re: [TLS] WGLC for delegated credentials

I have reviewed the diff, and I think this document is ready. Russ > On Sep 23, 2021, at 5:51 PM, Joseph Salowey wrote: > > This is a one week working group last call for draft-ietf-tls-subcerts-11. > Please focus on newer text for your review. Although it has been a while > since the last

Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-external-psk-guidance-04: (with COMMENT)

> == COMMENTS == > > -- Section 4.1 -- > A wild guess (as I do not know the details of TLS 1.3), but if a group member > is compromised and no ephemeral keys were used, then isn't the attacker able > to > read even the past/recorded traffic ? The document saysL 3. If PSK is not combined wit

Re: [TLS] Erik Kline's No Objection on draft-ietf-tls-external-psk-guidance-04: (with COMMENT)

> -- > COMMENT: > -- > > > [S4; nit] > > * s/quantum computes/quantum computers/? > > [S4.2; nit] > > * "including, for example, including ..." -> "includin

Re: [TLS] Murray Kucherawy's No Objection on draft-ietf-tls-external-psk-guidance-04: (with COMMENT)

> -- > COMMENT: > -- > > Thanks to Martin Thomson for his ARTART review. > > A stylistic point: The Abstract is made up of five sentences all of which > start >

Re: [TLS] Revised hybrid key exchange draft

I think that Martin is asking what properties this provides that justify the additional complexity. I'm sure that a few test vectors are sufficient to get interoperability, but what properties of the construction justify the effort to do something different? Russ > On Jan 22, 2022, at 6:35 A

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

> On Apr 29, 2022, at 8:24 PM, Stephen Farrell > wrote: > > On 27/04/2022 16:27, Christopher Wood wrote: >> This email commences a two week WGLC for draft-ietf-tls-hybrid-design, >> located here: >>https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ > > As I guess I've said b

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-13.txt

All of the changes are simple and straight forward. I did spot one typo: Section 4.2: s/This documnt defines/This document defines/ Russ > On May 9, 2022, at 8:37 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > Th

Re: [TLS] Extensibility in SCVP draft

I was thinking the same thing during the presentation. An extension for SCVP seems fine to me. Then in the future, if another validation comes along some day, a new extension can be assigned for that protocol. Russ > On Jul 25, 2022, at 4:13 PM, Martin Thomson wrote: > > Take this: > > str

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

Uri: You cannot do it with PKCS#10. That is why CRMF (RFC 4211) was created. RFC 2875 and RFC 6955 talk about the proof-of-possession (PoP) of 2875 Diffie-Hellman keys. A similar PoP specification will be needed for Kyber, and some folks agreed to write the -00 version before IETF 115 (nudge

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

e could define an extension that > produced an empty signature, so that it could be used for any algorithm > without these complications... > > On Wed, Oct 5, 2022, at 03:05, Russ Housley wrote: >> Uri: >> >> You cannot do it with PKCS#10. That is why CRMF (RFC 421

Re: [TLS] E164 in X509

One could use a certificate that has a subjectAltName with a tel: URI or a DNS name ending with .e164.arpa. Russ > On Oct 12, 2022, at 5:35 PM, Eric Rescorla wrote: > > Yes, but (D)TLS is agnostic to credential format. > > Would the certificate format in https://www.rfc-editor.org/rfc/rfc8226

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

There have been attempts in the past to signal this to product planners: SHOULD+This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST. SHOULD-This term means the sa

Re: [TLS] Minor RFC8446bis change

The proposed addition looks like excellent advice. Russ > On Jul 13, 2023, at 11:36 AM, Christopher Wood wrote: > > This final PR introduces some normative language, so we wanted to flag it on > the list before merging: > > https://github.com/tlswg/tls13-spec/pull/1325 > > If there are no

Re: [TLS] Adoption call for draft-jackson-tls-cert-abridge

I support adoption and am willing to review. -Original Message- From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of Christopher Wood Sent: Tuesday, August 1, 2023 12:36 PM To: TLS@ietf.org Subject: [EXTERNAL] [TLS] Adoption call for draft-jackson-tls-cert-abridge

Re: [TLS] [Editorial Errata Reported] RFC8773 (7598)

al > Pre-Shared Key". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7598 > > ------ > Type: Editorial > Reported by: Russ Housley > > Section: 5.1 > > Original Text

Re: [TLS] [EXTERNAL] New Version Notification for draft-ounsworth-lamps-pq-external-pubkeys-00.txt

Dennis: If we are going to allow a certificate to include pointers to externally stored public keys, I think a solution that works for the Web PKI and other PKI environment as well. I would not object to the use of abridged certs as an option, but I would object if it is the only option. Russ

Re: [TLS] [EXTERNAL] New Version Notification for draft-ounsworth-lamps-pq-external-pubkeys-00.txt

Dennis: >> If we are going to allow a certificate to include pointers to externally >> stored public keys, I think a solution that works for the Web PKI and other >> PKI environment as well. > > I'm trying to understand the use case of certificates with pointers to > externally stored public k

Re: [TLS] I-D Action: draft-ietf-tls-8773bis-00.txt

xt is now available. It is a work > item of the Transport Layer Security (TLS) WG of the IETF. > > Title: TLS 1.3 Extension for Certificate-based Authentication with an > External Pre-Shared Key > Author: Russ Housley > Name:draft-ietf-tls-8773bis-00.txt > Pages

Re: [TLS] I-D Action: draft-ietf-tls-8773bis-00.txt

khovni wrote: > > On Wed, Nov 29, 2023 at 10:49:42AM -0500, Russ Housley wrote: > >> People are implementing RFC 8773, so I would like to advance this to >> the standards track. In addition, this fixes the only errata that was >> posted against RFC 8773. >> >

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

I think this should move forward. I am encouraged that at least two people have spoken to me about their implementations. Russ > On Nov 29, 2023, at 10:51 AM, Joseph Salowey wrote: > > RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an > External Pre-Shared Key) was ori

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

9360 >>> >>> On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla >> <mailto:e...@rtfm.com>> wrote: >>>> What do we have in terms of formal analysis for this extension? >>>> >>>> -Ekr >>>> >>>> >>>

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

> On Dec 5, 2023, at 12:01 PM, Christian Huitema wrote: > > On 12/5/2023 8:13 AM, Russ Housley wrote: >> At IETF 104, I presented a slide with informal reasoning about TLS 1.3 >> Security. >> Authentication: >> The certificate processing is exactly the same.

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

Christian: > > Thanks. I am not 100% sure that we actually have an attack against the > [EC]DH+PSK combination, but I am confident than if the PSK secret is weak, > the attacker can get to the early data. If only for that, it is prudent to > use long enough PSK. As stated in draft-ietf-tls-877

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

John: I respond to your three suggested changes below: (1) How about a title of "TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key" (2) None of the normative references are paywalled. Two references are not RFCs or RFC errata or I-Ds or IANA web pages: [GGM1986

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

Stephen: Maybe. ECH would need to be updated to use PQC algorithms to get that protection. Ill add that point: Appendix E.6 of [RFC8446] discusses identity-exposure attacks on PSKs. Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses tracking prevention. The guidance in these

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

John: Thanks for you thoughtful review. > Russ Housley wrote: > > Appendix E.6 of [RFC8446] discusses identity-exposure attacks on > > PSKs. Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses > > tracking prevention. The guidance in these sections remain relev

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

John: > > But now when I look at TS 33.222 personally, I see that Section 5.3 actually > uses HTTP Digest for the Shared key-based client authentication, not TLS PSK > authentication. Thanks for getting back to me on this. Russ___ TLS mailing list TL

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

f the Encrypted Client Hello extension. I think you are correct, the "with algorithms that a secure against a CRQC" should be dropped. Russ > On Dec 6, 2023, at 4:21 PM, Stephen Farrell wrote: > > > Hiya, > > On 06/12/2023 21:06, Russ Housley wrote: >> S

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

Christian: >>> >>> Thanks. I am not 100% sure that we actually have an attack against the >>> [EC]DH+PSK combination, but I am confident than if the PSK secret is weak, >>> the attacker can get to the early data. If only for that, it is prudent to >>> use long enough PSK. >> As stated in draft

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

Stephen: > >> I've been thinking about your point. Some people want to use RFC >> 8773 to protect data that is transmitted today and recorded from the >> future invention of a quantum computer. To do this, the handshake >> includes the identifier for the external PSK, and an observer can get >>

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

Bas: Thanks. I've adjusted the proposed text to address your comments: Implementations must use a ciphersuite that includes a symmetric encryption algorithm with sufficiently large keys. For protection against the future invention of a CRQC, the symmetric key needs to be at least 12

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

Sean: I observe that ML-KEM is not a Elliptic curve group or a Finite Field Diffie-Hellman group. I really think we want to include sepport for KEMs. but a separate range is needed. I assume it will be carved out of the Elliptic curve group range. KEMs are not "key agreement" algorithms as s

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

it didn't work out. :-) > > On Thu, Mar 28, 2024 at 5:08 PM Russ Housley <mailto:hous...@vigilsec.com>> wrote: >> Sean: >> >> I observe that ML-KEM is not a Elliptic curve group or a Finite Field >> Diffie-Hellman group. I really think we want to inclu

Re: [TLS] Working Group Last Call for ECH

Joe: The ECH Internet-Draft includes this reference: [ECH-Analysis] "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello", November 2022. This reference does not provide enough information for anyone to locate the document. I think a reference

Re: [TLS] Working Group Last Call for ECH

Thanks. This URL gives access without a paywall: https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf Russ > On Apr 2, 2024, at 10:31 AM, Stephen Farrell > wrote: > > > Hiya, > > On 02/04/2024 15:17, Russ Housley wrote: >> Joe: >> The

Re: [TLS] [Last-Call] Genart last call review of draft-ietf-tls-keylogfile-01

heers, > Martin > > On Fri, Apr 12, 2024, at 14:30, Russ Housley via Datatracker wrote: >> Reviewer: Russ Housley >> Review result: Ready >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF docume

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

>>> And also: I'm sorry to have to say it, but I consider that >>> attempted weasel wording around the clear intent of 2804. The >>> clear and real effect if your wiretapping proposal were standardised >>> by the IETF would be that we'd be standardising ways in which >>> TLS servers can be compell

Re: [TLS] chairs - please shutdown wiretapping discussion...

Tony: I want to highlight that draft-green-tls-static-dh-in-tls13-01 does not enable MitM. The server does not share the signing private key, so no other party can perform a valid handshake. Further, the server is choosing to use a (EC)DH key that was generated by the key manager, so it is qu

Re: [TLS] chairs - please shutdown wiretapping discussion...

Stephen: > And to avoid a repeat of Russ' failed justification, many > protocols use and depend on TLS where the entity controlling > the TLS server private key materials is not the higher > layer sender or receiver, so all four points in the definition > in 2804 are fully met by your wiretapping

Re: [TLS] chairs - please shutdown wiretapping discussion...

Stephen: >> >>> And to avoid a repeat of Russ' failed justification, many protocols >>> use and depend on TLS where the entity controlling the TLS server >>> private key materials is not the higher layer sender or receiver, >>> so all four points in the definition in 2804 are fully met by your >>

Re: [TLS] chairs - please shutdown wiretapping discussion...

Stephen: > And to avoid a repeat of Russ' failed justification, many protocols > use and depend on TLS where the entity controlling the TLS server > private key materials is not the higher layer sender or receiver, > so all four points in the definition in 2804 are fully met

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

Travel plans were made based on the published agenda, an Matt Green will not be on Prague on Monday. We should not discuss draft-green- without him. Russ > On Jul 15, 2017, at 9:46 AM, Salz, Rich wrote: > > I would *VERY VERY STRONGLY* like to see the static-dh draft be on Monday, > and all

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

Martin: >>> At the point that I have sufficient control over a host that I can run >>> my software, then I would pin certificates and the best you could do >>> is block me. None of the advice about configuration of trust anchors >>> (pinning, overrides, etc...) helps at that point. >> >> Correct

[TLS] Is there a way forward after today's hum?

The hum told us that the room was roughly evenly split. In hind sight, I wish the chairs had asked a second question. If the split in the room was different for the second question, then I think we might have learned a bit more about what people are thinking. If a specification were available

Re: [TLS] Is there a way forward after today's hum?

violation for the server to include it. Russ > On Jul 19, 2017, at 1:14 PM, Ted Lemon wrote: > > Provably involved, or involved setting an evil bit? > > On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley <mailto:hous...@vigilsec.com>> wrote: > The hum told us that the ro

Re: [TLS] Is there a way forward after today's hum?

nce to? > > On Wed, Jul 19, 2017 at 10:10 AM, Russ Housley <mailto:hous...@vigilsec.com>> wrote: > The hum told us that the room was roughly evenly split. In hind sight, I > wish the chairs had asked a second question. If the split in the room was > different for

Re: [TLS] Is there a way forward after today's hum?

> On Jul 20, 2017, at 5:57 AM, Robin Wilton wrote: > > Apologies for not replying "in thread" on this occasion, for noob reasons... > but here's the specific comment from Russ that I wanted to respond to: > > The hum told us that the room was roughly evenly split. In hind sight, I > wish the

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

Nick: Thanks for this summary. This resolves my previous concerns. Russ > On Jul 18, 2017, at 7:06 AM, Nick Sullivan > wrote: > > Sean, > > We've had some additional discussions in person here at IETF 99 with folks > who were in the proxy certificates and short-lived certs camp, and we th

Re: [TLS] 32 byte randoms in TLS1.3 hello's

there was a discussion of adding a statement that a fresh ephemeral key MUST be used for each session. It was decided not to do that. Without such a requirement, nonces are needed. Russ > On Jul 24, 2017, at 12:40 PM, Dan Brown wrote: > > Hmm, I'd appreciate a brief reminder* of why 1.3 ne

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> For starters, though, I'd be interested answers from the authors > to two quick questions, though I suspect I can guess 'em: > > 1. TLS1.3 has had significant formal analysis. Did the authors > or other proponents here do any such work and if so can you send > a pointer to your results? If not,

Re: [TLS] Should CCM_8 CSs be Recommended?

> On Oct 4, 2017, at 3:30 AM, Yoav Nir wrote: > >(IoT) - This requirement is for interoperability with IoT. Only >128-bit keys are at the given level. If the IoT environment is willing to accept lower integrity protection in order to save a few bits on the wire/ether, I do not see why

Re: [TLS] Should CCM_8 CSs be Recommended?

> On Oct 4, 2017, at 9:48 AM, Yoav Nir wrote: > > >> On 4 Oct 2017, at 16:29, Russ Housley > <mailto:hous...@vigilsec.com>> wrote: >> >> >>> On Oct 4, 2017, at 3:30 AM, Yoav Nir >> <mailto:ynir.i...@gmail.com>> wrote: >&g

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Richard: > Thanks for the update here. I agree that this is an improvement over > draft-green-tls-static-dh-in-tls13, in particular because (1) it has a > mechanism for mutual consent and (2) it only touches the outputs of the > handshake, not the inputs. Thanks. > A couple of points to con

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Nick: Thanks for the review. I am willing to work on the missing details about the use of Ke. Russ > On Oct 9, 2017, at 4:49 PM, Nick Sullivan wrote: > > Ralph and Russ, > > This draft addresses the two main concerns I had with draft-green: > 1) Client opt-in > 2) On-the wire visibility >

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> On Oct 19, 2017, at 9:06 PM, Benjamin Kaduk wrote: > > On 10/19/2017 05:30 PM, Darin Pettis wrote: >> >> The question has been raised: "Why address visibility now?" The answer is >> that it is critical that the visibility capability is retained. It is >> available today through the RSA k

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Tony: > > Can you provide a *specific citation* as to where you will be *required* to > use TLS 1.3 any time in, say, the next decade? > No one is requiring TLS 1.3 that I know about. However, there are places that require visibility into TLS. I will let one of the people that works in a reg

Re: [TLS] Draft RHRD

Rich: > On Nov 1, 2017, at 10:18 AM, Salz, Rich wrote: > > In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html > , Nick > Sullivan concluded: > > >- on the other hand using draft-rhrd is safer than allowing organ

[TLS] External PSK with certificate-based authentication

At the bottom of page 136, the current draft says: Note: TLS does not currently permit the server to send a certificate_request message in non-certificate-based handshakes (e.g., PSK). If this restriction were to be relaxed in future, the client's signature would not cover the server'

Re: [TLS] External PSK with certificate-based authentication

> On Dec 2, 2017, at 1:51 PM, Eric Rescorla wrote: > > On Sat, Dec 2, 2017 at 10:10 AM, Russ Housley <mailto:hous...@vigilsec.com>> wrote: > At the bottom of page 136, the current draft says: > >Note: TLS does not currently permit the server to send a >

Re: [TLS] access_administratively_disabled v2

Mateusz: How do you see IANA controlling which parties get certificates for the access_administratively_disabled.net domain? Russ P.S. If I recall RFC 1034 and 1035 correctly, domain name labels may contain only letters, digits, and hyphen. Underscore is not allowed. > On Jan 3, 2018, at 7

Re: [TLS] WGLC for draft-ietf-tls-record-limit

> This is the working group last call for the "Record Size Limit Extension for > TLS" draft available at > http://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/. Please review > the document and send your comments to the list by 6 February 2018. Section 2: Please update the paragraph t

Re: [TLS] Recommended yes->no for max_fragment_length extension?

If the WG is going to publish the standards track RFC, then the extension it defines should say 'Yes' in the recommended column. Russ > On Feb 7, 2018, at 3:33 PM, Sean Turner wrote: > > All, > > Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG needs to > confirm that dr

Re: [TLS] Recommended yes->no for max_fragment_length extension?

t/pull/14 > > On Thu, Feb 8, 2018 at 7:37 AM, Russ Housley wrote: >> If the WG is going to publish the standards track RFC, then the extension it >> defines should say 'Yes' in the recommended column. >> >> Russ >> >> >>> On Feb 7, 201

Re: [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04

>> Minor issues: >> >> I think convention is to list the documents being updated in the Abstract, >> but >> cannot find any formal guidance. > > You’re right that is the convention, but it’s not required. > draft-flanagan-7322bis is attempting to make including updates in the > abstract a mu

Re: [TLS] Opsdir last call review of draft-ietf-tls-iana-registry-updates-04

> On Feb 20, 2018, at 05:44, Dan Romascanu wrote: > > Reviewer: Dan Romascanu > Review result: Has Issues > > I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate reviews > a great part of the IETF documents being processed by the IESG for the OPS > ADs. > Please treat with t

[TLS] New Internet-Draft: draft-housley-tls-tls13-cert-with-extern-psk-00

eliminate the man-in-the-middle attack that they found in 2015. Thanks, Russ > From: internet-dra...@ietf.org > Subject: New Version Notification for > draft-housley-tls-tls13-cert-with-extern-psk-00.txt > Date: March 1, 2018 at 4:13:44 PM EST > To: "Russ Housley" >

Re: [TLS] New Internet-Draft: draft-housley-tls-tls13-cert-with-extern-psk-00

Martin: > > This seems like a welcome addition. I'm not sure why you think that > PQ needs are a good motivation for this work though. Managing > external PSKs is so unwieldy that it almost seems like this would do > more harm than good in that regard. I find this more interesting from > the pe

[TLS] New Version Notification for draft-rhrd-tls-tls13-visibility-01.txt

A few minutes at the TLS WG session in London have been requested to talk about this draft. Russ > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-rhrd-tls-tls13-visibility-01.txt > Date: March 2, 2018 at 3:58:35 PM EST > To: "Ralph Droms

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

>> Stephen, the opposite PoV is equally valid. There was no consensus in >> Prague NOT to work on the topic. The mood of the room was evenly >> divided. > > To clarify, this isn't voting. If there's no agreement in > either direction there's no agreement (and I hope the default > in the IETF is

Re: [TLS] TLS@IETF101 Agenda Posted

Ted: > There's an easy way to do this, although as a sometime bank security geek I > would strongly advise you to not do it: keep using TLS 1.2. This is a bogus argument. First, staying with an old protocol version often leads to locking in unmaintained versions of old software. Second, using

Re: [TLS] TLS@IETF101 Agenda Posted

> On Mar 13, 2018, at 6:21 PM, Andrei Popov wrote: > > If the client were to exclusively offer DHE-based ciphersuites, then the > visibility techniques that have been used in the past are thwarted. > TLS1.3-visibility will be equally thwarted if the client does not send the > empty “tls_visibi

Re: [TLS] TLS@IETF101 Agenda Posted

Ted: I do not follow. >> This is a bogus argument. > > I'm pretty sure there's a Monty Python skit about this, so I won't belabor > the point. I'll avoid asking how many sparrows are needed ;-) >> First, staying with an old protocol version often leads to locking in >> unmaintained versions

  1   2   3   >