Re: [TLS] Packet number encryption negotiation

es, the encryption > hardware has to obtain at most the first 32 bytes of the encrypted > payload before applying the header protection, and forwarding the header > and these 32 bytes. Yes, this is harder than not doing it at all. And > yes, th

Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension

lps >> >> >> >> >> >> On Wed, Sep 27, 2023 at 1:40 AM Martin Thomson wrote: >> >> On Wed, Sep 27, 2023, at 01:32, Hewitt, Rory wrote: >> > Apologies if I should respond directly to the mailing list

Re: [TLS] DNS-based Encrypted SNI

ue that the deployability issue is a concern related to the non-use of prefix. It is _not_ related to the selection of the record type. OTOH, I think that the reliability issue related to using a new record type exists, as others have pointed out. > > -Ekr > > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DNS-based Encrypted SNI

> encoding makes any difference. >> >> All that said, I did just suggest adding in the dummy sni >> value:-) So I mostly think if this goes ahead (as I hope it >> does), we spend a bit of time considering the above issues >> before we're done. > > > Sure, that seems reasonable. I think you are getting to something > important here: my philosophy here is that this should be a more > or less opaque blob which you provide to the TLS stack. So I'm > optimizing for what's convenient for that. I can understand that > others might feel differently. > > -Ekr > >> >> Cheers, >> S. >> > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ESNI robustness and GREASE PRs

t the other, the > text and details can be adjusted accordingly.) > > Thoughts? > > David > > [*] Steven and I wrote the text itself, with input from Adam, Ben, and Brad, > all CC'd. > > ___ > TLS mailing list >

Re: [TLS] Two Multi-CDN proposals

of the authors) > > [1] https://mailarchive.ietf.org/arch/msg/tls/WXrPgaIsIPItDw3IQthmJk9VRlw > > _______ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Two Multi-CDN proposals

2019年3月2日(土) 1:57 Christopher Wood : > > On Wed, Feb 27, 2019 at 11:34 PM Kazuho Oku wrote: > > > > Hi Chris, > > > > Thank you for writing down the PRs describing possible designs that we > > might adopt. I think it helps a lot in understanding the details

Re: [TLS] Two Multi-CDN proposals

is safe, although it may be >> inconvenient for some operators, and it's not clear to me that #137 can be >> made to work without frequently incurring another serialized DNS query. If >> we had some evidence to the contrary, I would be somewhat more favorable to >> #137, though I would probably still prefer #136 for reasons of simplicity, >> especially as we can always add #137 later if it proves viable.. >> >> >> >> -Ekr >> >> >> >> >> >> >> Note that this does not mean we must choose between #136 and #137 >> right now. We can do both (after possibly simplifying #137!), use >> them, and see what works best in practice. >> >> Anyway, I hope this summary accurately captures the differences and >> possible tradeoffs. >> >> 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 > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for draft-davidben-tls-batch-signing

+1 for adoption. 2019年11月21日(木) 18:49 Salz, Rich : > I am against the working group NOT adopting this. > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/t

[TLS] HMAC context of ClientFinished in TLS 1.3

discordance with the statement that it could be implemented using a running hash. Is this an error in the draft? -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] HMAC context of ClientFinished in TLS 1.3

Hi, Thank you very much for the clarification and the advise. I had indeed forgotten to consider the client certificate and its verify message. iPhoneから送信 2016/10/07 19:14、Ilari Liusvaara のメッセージ: >> On Fri, Oct 07, 2016 at 06:41:35PM +0900, Kazuho Oku wrote: >> Hi, >>

[TLS] Newcomer’s Implementation Experience of TLS 1.3 Draft 16

providing answers to my issues. I am looking forward to seeing it formalized. -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Newcomer’s Implementation Experience of TLS 1.3 Draft 16

iki? > https://github.com/tlswg/tls13-spec/wiki/Implementations and you would be > most welcome to n join the next hackathon in Seoul. Thank you for the offer. I added my implementation to the wiki. > > > On 13 Oct 2016 5:17 PM, "Kazuho Oku" wrote: >> >>

[TLS] Which SHA function should I use for CertificateVerify of a rsa_pkcs1_sha1 certificate?

4.4.2) So my question is, which signature algorithm am I supposed to use for a rsa_pkcs1_sha1 certificate? I'd assume that the answer is rsa_pss_sha256, but I could not find any such indication within the draft. -- Kazuho Oku ___ TLS mailing lis

Re: [TLS] Which SHA function should I use for CertificateVerify of a rsa_pkcs1_sha1 certificate?

ndle PKCS1 and SHA1 differently in protocol implementations? Thank you in advance. 2016-10-14 13:38 GMT+09:00 Kazuho Oku : > Hi, > > In TLS 1.3, my understanding is that the digest function negotiated > using the Signature Algorithm should be used for generating > CertificateVerif

Re: [TLS] Newcomer’s Implementation Experience of TLS 1.3 Draft 16

public so that I could use it for debugging? Thank you in advance. 2016-10-14 5:33 GMT+09:00 Ilari Liusvaara : > On Thu, Oct 13, 2016 at 12:18:03PM +0300, Ilari Liusvaara wrote: >> On Thu, Oct 13, 2016 at 03:17:32PM +0900, Kazuho Oku wrote: >> > TLDR: the spec. was clear and easy

Re: [TLS] draft-ietf-tls-tls-13-17 posted

outstanding PRs are: > #680: Forbid post-handshake authentication except when permitted by > application profile. This is almost entirely a requirements-level > change, though it would allow clients to send "unexpected_message" > when receiving

Re: [TLS] PR #699: Simplify traffic key expansion

ret, [sender]_handshake_traffic_secret, > [sender]_traffic_secret_N respectively > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR #699: Simplify traffic key expansion

Hi Martin, Thank you for your response. 2016-10-21 8:05 GMT+09:00 Martin Thomson : > On 21 October 2016 at 06:52, Kazuho Oku wrote: >> Is there any need to expand resumption_psk from resumption_secret? >> >> To me, it is unclear why resumption_secret cannot be used direct

Re: [TLS] draft-ietf-tls-tls-13-17 posted

't it be "client" as the AFAIK the > server won't send it? > > > -Ilari > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-tls13 posted

elcome. > > -Ekr > > P.S. NSS will be skipping draft-17 and going right to -18. This > should happen before Seoul. > > > _______ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-tls13 posted

2016-10-27 14:30 GMT+09:00 Eric Rescorla : > > > On Thu, Oct 27, 2016 at 4:27 PM, Kazuho Oku wrote: >> >> Hi, >> >> Thank you for posting draft-18, and thank you for the simplification of >> RMS. >> >> I have finished implementing resumption an

Re: [TLS] Fwd: New Version Notification for draft-thomson-tls-tls13-vectors-00.txt

t be reproduced. >Intermediate values, including secrets, traffic keys and ivs are >shown so that implementations might be checked incrementally against > these values. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Verifying the second HelloRequest in TLS 1.3

ruct an semantically identical ClientHello that looks different at byte level. I think the latest draft can be interpreted in either way (please correct me if I am wrong), and would like to learn what the answer would be. Thank you in advance. -- Kazuho Oku __

Re: [TLS] Confirming consensus: TLS1.3->TLS*

gt; interface that doesn't require additional education in the first place. >> >> ---Dan >> >> ___________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > > -- > konklone.com | @konklone <https://twitter.com/konklone> > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#812: End Of Early Data as handshake

t; TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] TLS 1.3: HRR vs. resumption

. Having such a guideline might reduce the chance of us creating a vulnerability. -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-thomson-http-replay-00.txt

This document explains the risks of using early data for HTTP and >describes techniques for reducing them. In particular, it defines a >mechanism that enables clients to communicate with servers about >early data, to assure correct operatio

Re: [TLS] Fwd: New Version Notification for draft-thomson-http-replay-00.txt

Hi Willy, 2017-06-26 17:01 GMT+09:00 Willy Tarreau : > Hi Kazuho, > > On Mon, Jun 26, 2017 at 04:03:24PM +0900, Kazuho Oku wrote: >> One question: is the name `early-data` a good choice? >> >> The reason I raise the concern is because what the header suggest is >>

Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-00.txt

e time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-02.txt

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 -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt

aft-kazuho-protected-sni-00.txt To: Kazuho Oku A new version of I-D, draft-kazuho-protected-sni-00.txt has been successfully submitted by Kazuho Oku and posted to the IETF repository. Name: draft-kazuho-protected-sni Revision: 00 Title: TLS Extensions for Protecting SN

Re: [TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt

asily surveilled, censored, or > blocked mechanism to enable other sorts of privacy are concerning. > > -tom > > > On 18 July 2017 at 22:42, Kazuho Oku wrote: >> Hi, >> >> I am happy to see us having discussions on how to protected SNI. I am >> also happy to see

Re: [TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt

Hi, Thank you for your comments. 2017-07-19 7:05 GMT+02:00 Ilari Liusvaara : > On Wed, Jul 19, 2017 at 05:42:24AM +0200, Kazuho Oku wrote: >> Hi, >> >> I am happy to see us having discussions on how to protected SNI. I am >> also happy to see that draft-huitema-tls-

[TLS] Re: Implicit ECH Config for TLS 1.3 – addressing public_name fingerprinting

gt; This change may have fit into the main ECH draft if it had been proposed > earlier. However, ECH has already been submitted to IESG for publication, > so I put this together as a standalone extension. I welcome your feedback > on this proposal as we work to reduce fi