Re: [TLS] padding

Dave: > On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote: >> On 17 May 2015 at 14:32, Dave Garrett wrote: >>> Is it really necessary to have a separate application_data_padded content >>> type? It'd be simpler to just keep using existing types but amend it with a >>> padding field and requi

[TLS] TLS 1.3 Key Schedule

In Section 7.1, the document says: 4. finished_secret = HKDF-Expand-Label(xSS, "finished secret", handshake_hash, L) 5. resumption_secret = HKDF-Expand-Label(master_secret,

Re: [TLS] TLS 1.3 Key Schedule

a wrote: > See: > http://www.ietf.org/mail-archive/web/tls/current/msg17184.html > > On Fri, Sep 4, 2015 at 8:27 AM, Russ Housley wrote: > In Section 7.1, the document says: > > 4. finished_secret = HKDF-Expand-Label(xSS, >

Re: [TLS] PR for PSS support

This text appears in two places (lines 3026 and 3180) +Only RSA signatures based on RSASSA-PSS MAY be used, regardless of whether +RSASSA-PKCS-v1_5 appears in "signature_algorithms". I think it would be better to say: +RSA signatures MUST be based on RSASSA-PSS, regardless of whether +RSASSA-PKC

Re: [TLS] PR for PSS support

Line 2816 allows SHA-224 in certification paths. I do not think TLS 1.2 provided that support. Russ On Sep 10, 2015, at 7:28 PM, Dave Garrett wrote: > On Thursday, September 10, 2015 04:18:24 pm Eric Rescorla wrote: >> Note that I didn't deprecate SHA-1 (something Hanno suggested) but I expec

Re: [TLS] Call for consensus to remove anonymous DH

> There has been some discussion to remove anonymous DH as described in > https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think > ekr's message sums up the pros and cons well. I don't think we have > consensus on this issue yet. Please respond on this message by Monday, >

Re: [TLS] Version in record MAC

Option #2 seems fine to me. Russ On Oct 19, 2015, at 12:28 PM, Eric Rescorla wrote: > Folks, > > https://github.com/tlswg/tls13-spec/issues/278 > > The additional data field presently includes the version: > > additional_data = seq_num + TLSPlaintext.record_version > > However, TLSPla

Re: [TLS] Controlling use of SHA-1

I am also in favor of this change: it prohibits the server to send SHA-1 certs when signature_algorithms does not include SHA-1. Russ On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson wrote: The current draft permits the use of SHA-1 in the certificate chain, which gives SHA-1 a free pass ind

Re: [TLS] TLS 1.3 - Just ditch compression

I thought we already decided to remove compression from TLS 1.3. Russ On Oct 8, 2015, at 10:10 PM, Scott Arciszewski wrote: > Based on CRIME and BREACH we know that this construction is not secure: > > C = encrypt(compress(A || B)) > > If you control B and A contains sensitive information, st

Re: [TLS] SHA-1 patch updated with Russ' suggestion

Martin: > Nitpicks accepted, pull requests preferred: > > https://github.com/tlswg/tls13-spec/pull/317 It might be useful to remind people about the difference between self-signed certificates and self-issued certificates. RFC 5280 says: Self-signed certificates are self-issued certificate

Re: [TLS] PR#345: IANA Considerations

+1. This seems like a reasonable way forward. Russ On Nov 17, 2015, at 12:51 PM, Eric Rescorla wrote: > There are presently four categories of cipher suites vis-a-vis TLS 1.3. > > 1. MUST or SHOULD cipher suites. > 2. Standards track cipher suites (or ones we are making ST, like > the ECC

Re: [TLS] Data volume limits

On Dec 15, 2015, at 4:14 PM, Eric Rescorla wrote: > Watson kindly prepared some text that described the limits on what's safe > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower > limit (2^{36} bytes), even though ChaCha doesn't have the same > restriction. > > I wanted to ge

Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

On Jan 25, 2016, at 2:43 PM, Hubert Kario wrote: > On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote: >> On 01/22/2016 01:14 PM, Hubert Kario wrote: >>> On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote: On 01/22/2016 03:14 AM, Hubert Kario wrote: >> The only solution that's a

Re: [TLS] Remove 0-RTT client auth

+1 On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson wrote: I'm sitting here in TRON listening to Karthik describe all the various ways in which client authentication in 0-RTT is bad. I'm particularly sympathetic to the perpetual impersonation attack that arises when the client's ephemeral key

Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint

It makes sense to me that the lifetimes be the same. Russ On Feb 23, 2016, at 12:42 PM, Nick Sullivan wrote: > Draft 11 currently supports both ServerConfiguration and PSK + Session Ticket > for session resumption (0RTT or otherwise). Both mechanisms have the same > properties in terms of 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

[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

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

Stephen: >> I do not know if the TLS WG will want to adopt this approach. I >> would like to find out. > > Did you read the list traffic from Oct/Nov? I have no idea how > you can be in doubt if you did. It's readily apparent that your > draft has not caused a lot of people to change their mind

Re: [TLS] TLS@IETF101 Agenda Posted

Second, using TLS1.2 does not technically address the issue. If the client were to exclusively offer DHE-based ciphersuites, then the visibility techniques that have been used in the past are thwarted. >>> >>> The client in this case is under the control of the operator, so this i

Re: [TLS] TLS@IETF101 Agenda Posted

> On Mar 14, 2018, at 8:39 AM, Hubert Kario wrote: > > On Tuesday, 13 March 2018 23:16:47 CET Russ Housley wrote: >> 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 usin

Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)

> On Mar 14, 2018, at 4:48 AM, Martin Thomson wrote: > > On Tue, Mar 13, 2018 at 9:49 PM, Russ Housley wrote: >> Nick Sullivan summarized >> four concerns with that approach. See >> https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg >> >

Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)

> On Mar 14, 2018, at 9:42 AM, Salz, Rich wrote: > > >> So aside from enabling MitM, this also enables session resumption by >the decryption service, something that the security considerations >neglects to include in its list. > > So I think this is an important point. I assume the

Re: [TLS] TLS@IETF101 Agenda Posted

>> Nalini, why don't you (the consortium) define the standard, then? > Indeed, if a “TLS13-visibility” standard has to be defined, it would make > sense for the consortium (rather than the TLS WG) to define it. In fact, my mistake that was caught by Martin is exactly the reason that we want th

Re: [TLS] TLS@IETF101 Agenda Posted

>> >> Nalini, why don't you (the consortium) define the standard, then? >> >> > Indeed, if a “TLS13-visibility” standard has to be defined, it would make >> > sense for the consortium (rather than the TLS WG) to define it. >> >> In fact, my mistake that was caught by Martin is exactly the re

[TLS] draft-housley-tls-tls13-cert-with-extern-psk

In London, I was on the agenda to talk about certificate-based authentication with external pre-shared key (PSK). We ran out of time, and I did not get to make the presentation. The slides are in the proceedings; see https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-certi

Re: [TLS] draft-housley-tls-tls13-cert-with-extern-psk

> On Apr 23, 2018, at 5:01 AM, Nikos Mavrogiannopoulos wrote: > > On Wed, 2018-04-18 at 12:25 -0400, Russ Housley wrote: >> In London, I was on the agenda to talk about certificate-based >> authentication with external pre-shared key (PSK). We ran out of >> time, an

Re: [TLS] Reserve or close HashAlgorithm and SignatureAlgorithm registries?

I think that reserving them is the right thing for now. TLS 1.2 and earlier will take a while to disappear, so the ability to assign more values if there is a huge surprise seems prudent. Russ > On May 4, 2018, at 3:54 PM, Sean Turner wrote: > > The open issue in draft-ietf-tls-iana-registr

Re: [TLS] WG adoption call: draft-housley-tls-tls13-cert-with-extern-psk

My recollection is that we would do a call for adoption, and that would lead to comments, and then I post an update. If the comments are addressed adequately, then the update will be adopted, otherwise not. Russ > On Jul 26, 2018, at 8:16 PM, Martin Thomson wrote: > > I think that we need a

Re: [TLS] draft-housley-tls-tls13-cert-with-extern-psk

> On Jul 27, 2018, at 5:23 AM, Nikos Mavrogiannopoulos wrote: > > On Mon, 2018-04-23 at 15:30 -0400, Russ Housley wrote: >>> >>> In the presentation the main driver for it seems to be quantum >>> computer >>> resistance as temporary measure. If t

Re: [TLS] Minutes for TLS IETF 102 uploaded

I do not understand the formatting. Are the '*' characters supposed to be bullets? If so, them appearing in the middle of paragraphs is confusing. Russ > On Jul 28, 2018, at 1:32 PM, Christopher Wood > wrote: > > Minutes for both TLS sessions at IETF 102 have been uploaded: > https://datat

Re: [TLS] Minutes for TLS IETF 102 uploaded

and let me know if you > see other (or new) issues. > > Best, > Chris > > On 9 Aug 2018, at 21:53, Kaarthik Sivakumar wrote: > > Could be line ending issues - I see something like these when switching > between different OSes. > > -kaarthik- > > On 10/0

[TLS] New Version Notification for draft-housley-tls-tls13-cert-with-extern-psk-01.txt

ls13-cert-with-extern-psk-01.txt > Date: August 16, 2018 at 1:06:14 PM EDT > To: "Russ Housley" > > > A new version of I-D, draft-housley-tls-tls13-cert-with-extern-psk-01.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. &g

Re: [TLS] I-D Action: draft-housley-tls-tls13-cert-with-extern-psk-02.txt

net-Drafts > directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > >Title : TLS 1.3 Extension for Certificate-based > Authentication with an External Pre-Shared Key > Author : Russ Housley > Filenam

Re: [TLS] I-D Action: draft-housley-tls-tls13-cert-with-extern-psk-02.txt

David: Thanks for reading the draft. > The resumption flow in this draft looks odd to me. While the handshake flow > is the same, the use cases differ between which identity should be in play > and when to use it. Separate extensions and documents may be better. (I > suppose saying the semanti

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

The document says: /* Managed by IANA */ enum { X509(0), RawPublicKey(2), 1609Dot2(?), /* Number 3 will be requested for 1609.2 */ (255) 103097(?), /* Number 4 will be requested for 103097 */ (255) } CertificateType; Two

Re: [TLS] External PSK importers

> On Oct 30, 2018, at 2:26 AM, Christian Huitema wrote: > > On 10/29/2018 9:56 PM, Martin Thomson wrote: > >> You should do something more concrete with the label parameter. Keep >> in mind that both client and server need to agree on a use for this, >> so my initial intuition to put the ser

Re: [TLS] Proposed Errata for rfc5246

The intent is that the server pick the most preferred signature algorithm that is supported and meets local policy. Given the local policy aspect of the server's choice, it can be any one offered by the client. The client should not offer any that are not acceptable according o their local pol

Re: [TLS] A new draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)" has been updated

Haiguang: Like Ilari, I am a bit confused about the specification for TLS 1.2 but not TLS 1.3. It seems that the pros and cons of an identity-based approach are the same in bot environments. When I quickly went through the document, I did not understand client authentication. I guess I can f

  1   2   3   >