On Mon, Jan 6, 2025 at 6:14 PM Eric Rescorla wrote:
>
>
>
> On Mon, Jan 6, 2025 at 11:31 AM Michael Richardson
> wrote:
>>
>>
>> Please note and respect the Reply-To: uta@ietf.org.
>>
>>
>>
>> 4. Find a sensible way to extend RFC6066 to accomodote other forms of SNI.
>> There isn't an IANA regis
On Sat, Sep 28, 2024, 6:16 AM Viktor Dukhovni
wrote:
> On Fri, Sep 27, 2024 at 11:55:52AM -0700, Watson Ladd wrote:
>
> > Spurred by recent IDs and events I've been thinking harder about how
> > to get what we want out of TLS, DNS, and their interaction at the
> >
work,
>> even if we could resolve extra records reliably.
>>
>> To my mind the registry should be able to issue X509 certs for second
>> level domains/whoever controls a public suffix. After all, they know
>> where you change DNS. Haven't sorted out how to
rols a public suffix. After all, they know
where you change DNS. Haven't sorted out how to deal with the level
below that. Do others find this line of thought compelling?
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
___
Uta mailin
>
> thanks,
> Rob
>
> There are two other pieces of feedback that seem reasonable to me, but they
> didn't come with spec text, and I'm not sure how to incorporate them:
>
> Regarding Section 7.3, Watson Ladd writes:
> "I think we actually need to say
er
> applications often end up using the more liberal approach in [UTS-46].
> ---
I think we actually need to say more here: the A-label used in the
X509 comparison needs to be the A-label derived and used to do the DNS
lookup. Otherwise we have the issue of bugs that change the IDN
beh
tantly, no matter what we say. If your PKI cannot reissue
the end-entity certs at issue, you have a very broken PKI: what
happens when certificates are compromised? IEEE 802.1AR can roll out
after we say "You MUST use the SAN" just as they rolled out TLS 1.2
after it was created.
Sincerel
On Sat, Oct 31, 2015 at 1:06 AM, Viktor Dukhovni wrote:
> On Fri, Oct 30, 2015 at 12:00:30PM +0100, Aaron Zauner wrote:
>
>
> STARTTLS is designed to thwart exactly one attack: *passive* wiretap.
> It works as designed for just that attack. It is not surprising
> that active attacks can and do d
On Jul 31, 2015 8:49 AM, "Viktor Dukhovni" wrote:
>
> On Fri, Jul 31, 2015 at 08:33:31AM -0700, Watson Ladd wrote:
>
> > > Perhaps you're using the phrase "local resolver" in some novel way
> > > that I don't understand. Why shouldn
On Jul 31, 2015 8:29 AM, "Viktor Dukhovni" wrote:
>
> On Thu, Jul 30, 2015 at 04:02:58PM -0400, Keith Moore wrote:
>
> > And finally, the idea that a DNS client
> > could simply trust its local resolver to do DNSSEC validation for it
never
> > made any sense at all.
>
> Perhaps you're using the ph
On Feb 19, 2015 10:01 AM, "Barry Leiba" wrote:
>
> > Barry, following up, here is some proposed text (again, not yet
coordinated
> > with my co-authors).
>
> Nice text all 'round; thanks.
>
> One question on one of them:
>
> > OLD
> >Implementations and deployments SHOULD disable TLS-level com
being similar to the existing WebPKI, or is DANE validation or
something else being suggested somewhere else?
Sincerely,
Watson Ladd
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
door? Some of the issues being
addressed are easily exploitable, recurring security issues.
Sincerely,
Watson Ladd
>
> Peter
>
> --
> Peter Saint-Andre
> CTO @ &yet
> https://andyet.com/
>
> ___
> Uta mailing list
>
t; different and interesting ways.
>
> But in general I'd agree that it's a bit early to be building something
> completely new, given that OAuth is of recent vintage.
What exactly is being copied? RFC 6749 doesn't provide a way to ensure
cookie stealing doesn't happen. Access t
bout this whole subject: I can see some
potential security issues involving repeated parsing of bound tokens.
Sincerely,
Watson ladd
>
> Cheers,
>
> Andrei
>
> -Original Message-
> From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Ilari Liusvaara
> Sent: Thursday
authentication mechanisms? Is this something we can fix in TLS 1.3, or
not?
Sincerely,
Watson Ladd
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
>> Servers SHOULD authenticate using at least 2048-bit certificates.
>
> That's OK. I wish we could use stronger words about TWIRL (since I would be
> flabbergasted if one hadn't been created, and surprised if it hadn't been
> improved on), but I think that's
On Fri, Oct 24, 2014 at 9:20 AM, Yaron Sheffer wrote:
> Hi Watson,
>
> Please see below.
>
> Yaron
>
> On 10/24/2014 06:41 PM, Watson Ladd wrote:
>>
>>
>> Section 2, bullet 3 seems to include STMP. It's unclear if this is in
>> fact corre
Section 1, penultimate paragraph, says TLS 1.3 will obsolete this
document. It's not clear why, especially given that TLS 1.3 is likely
to have a lengthy time to be adopted, and won't contain
recommendations for other versions.
Section 2, bullet 3 seems to include STMP. It's unclear if this is in
Dear all,
SSLv3 is busted once again. We need to fully disable it. The issue is an
enhanced padding oracle attack discovered at Google. This is not timing
based: there is no cure. Reconciliation with the result on MAC then encrypt
security is left as an exercise to the reader.
Sincerely,
Watson
On Oct 13, 2014 1:07 PM, "Yaron Sheffer" wrote:
>
> Hi Stephen,
>
> Thanks for your review. Here are a few comments to your comments.
>
>
> On 10/13/2014 07:27 PM, Stephen Farrell wrote:
>>
>>
>> - s2, 2nd para: "a more systemic solution" is left hanging
>> - do you mean TLS1.3? If so, maybe say s
On Sun, Oct 5, 2014 at 7:08 PM, Sean Turner wrote:
> On Oct 03, 2014, at 09:42, Viktor Dukhovni wrote:
>
>> On Thu, Oct 02, 2014 at 05:20:56PM -0400, Sean Turner wrote:
>>
>>> The deployment recommendations address the operators of application
>>> layer services that are most commonly used on t
Dear all,
At least 99% of the time, traffic goes over TLS to protect it from
prying eyes. And very often, this is not the case because of various
failures: from the lack of hostname validation, to the misuse of
ciphers in old versions, or the use of non-PFS suites and eventual key
compromise. This
On Aug 18, 2014 8:12 AM, "Paul Hoffman" wrote:
>
> On Aug 17, 2014, at 5:38 PM, Will Sargent
wrote:
>
> > Rather than "please implement the RFC correctly", I'd say "please test
that your implementation correctly implements hostname verification, using
dnschef or another spoofer. I have an example
On Aug 17, 2014 2:50 PM, "Paul Hoffman" wrote:
>
>
> On Aug 17, 2014, at 2:19 PM, Watson Ladd wrote:
>
> > To be clear, reusing exponents
> > means an attacker who rolls up, grabs the server and snarfs RAM along
> > with the disks has every bit of dat
gh that
server. This is only marginally an improvement from no ephemeral key
exchange, and it's something that people designing systems based on
TLS need to be aware of.
Sincerely,
Watson Ladd
>
> Thanks,
> Yaron
>
>
> On 08/17/2014 08:38 PM, Watson Ladd wrote
hat?
>
> Thanks, Yaron
>
> On 17 August, 2014 8:12:38 PM GMT+02:00, Watson Ladd <
watsonbl...@gmail.com> wrote:
>>
>> On Sun, Aug 17, 2014 at 9:22 AM, Ralph Holz wrote:
>>>
>>> EDIT: And of course, RFC 5280 describes the process of correct hostn
x27;s okay: we're taking optional behavior and saying "yes,
this is good, but alternatives aren't".
Sincerely,
Watson Ladd
>
>
> Hi,
>
>>> We seem to be woefully short on advice dealing with hostname
>>> validation. This is probably the real world pr
On Aug 13, 2014 10:30 AM, "Will Sargent" wrote:
>
> There's a typo on "Triple Hanshake" and "the are" instead of "there are".
>
> The mention of AES-GCM is only optimal if using hardware and counters
(see the router link below), otherwise the random nonce is too small. I'm
not sure if this is a pr
the ECDH or DH ones.
Sincerely,
Watson Ladd
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
I'm sorry: unless you've written Lucky 13 proof code you shouldn't say
it's an implementation error.
Implementing the old TLS ciphersuites in a constant time manner took
AGL 500 lines of C. It's a herculean effort, one
that could be avoided by reversing the order of encryption and macing in TLS.
S
en TLS 1.0 is negotiated?
Furthermore, we should mention workarounds for Triple Handshake and Lucky 13.
I think we mention CRIME already.
Sincerely,
Watson Ladd
>
> If you need a citable source, we might have to ask Ivan Ristic for data
> from SSLPulse. TUM is not going to publish
but watch as someone says "well, I got this sewage treatment plant
that runs on a VAX, and when it breaks we'll replace it, but until
then..." This is not an imaginary problem: I seem to remember
discussion of a Cisco protocol that stepped on what was once supposed
to be a port fo
DSA).
Performance matters: many servers don't support DH+RSA for performance
reasons, requiring ECDH instead. If clients don't support it, the
fallback is to non-PFS suites.
Clients don't validate DH parameters, and there is no list to check
against, which needs to be fixed be
s well due to Triple Handshake. We
might as well throw this in: it doesn't hurt. However, if you aren't
doing it already, odds are you aren't capable of implementing TLS
correctly, because you don't understand the issues associated with
implementing cryptography.
Sincerely,
Watson
thermore, taking an economic perspective, authentication has a
winner-take-all aspect to it. A new client has to support the
authentication everyone already uses. But a site only has to support
the authentication the client accepts. Any new authentication
mechanism wi
36 matches
Mail list logo
